Logiciel d’optimization de la supply chain, février 2025

Par Léon Levinas-Ménard

Dernière modification: 2 février 2025

Classement des fournisseurs & résumé (basé sur la rigueur technique)

Lokad – Crédibilité technique de pointe. Lokad se distingue par sa transparence et sa profondeur technique. Elle a été pionnière dans la prévision probabiliste et a prouvé l’efficacité de ses méthodes en compétition ouverte (obtenant le classement #1 au niveau SKU et #6 au classement général parmi 909 équipes dans le concours de précision des prévisions M5 ¹ – la seule équipe dirigée par un fournisseur figurant parmi les meilleurs). Lokad publie des analyses détaillées sur son architecture (par exemple, un langage spécifique au domaine appelé Envision, une automatisation basée sur le cloud) et met l’accent sur des décisions optimisées financièrement plutôt que sur des indicateurs simplistes. Son accent mis sur les mathématiques rigoureuses (prévisions quantiles, optimisation stochastique) et sur des flux de travail entièrement scriptables et automatisés (via des API et de la programmation) démontre une conception axée sur l’ingénierie. Aucune revendication grandiloquente en matière d’AI/ML n’est faite sans fondements – à la place, Lokad fournit des livres blancs techniques et même des outils open-source pour gérer des données dépassant les limites de la RAM ² ³. Ce niveau d’ouverture et de performance éprouvée place Lokad au sommet.
Anaplan – Plateforme “Excel 2.0”. Anaplan est essentiellement la version SaaS d’entreprise d’un tableur, propulsée par son moteur en mémoire propriétaire Hyperblock ⁴. Techniquement, Hyperblock est un moteur de calcul multi-dimensionnel robuste qui permet à des milliers d’utilisateurs de collaborer en temps réel sur des modèles de planification – semblable à un Excel basé sur le cloud, superchargé. Bien qu’Anaplan ne soit pas spécifiquement un optimiseur de supply chain (la prévision et l’optimisation algorithmique y sont considérées comme des « citoyens de seconde zone » ⁵), sa force réside dans son architecture solide pour la modélisation et la planification de scénarios. Il ne vend pas de l’IA mystique ; il offre plutôt un bac à sable fiable et performant pour construire une logique de planification sur mesure. En bref, c’est un outil de planification général puissant avec une approche honnête – aucune revendication exagérée sur une magie de la prévision, juste un système de type tableur bien conçu et évolutif. Cette proposition technique simple confère à Anaplan une haute crédibilité.
Kinaxis (RapidResponse) – Moteur de simulation en mémoire. Kinaxis est connu pour son moteur de concurrence unique qui permet de recalculer sur le vif les plans supply chain dans toute l’entreprise. Techniquement, Kinaxis a construit son propre moteur de base de données à partir de zéro pour supporter cela ⁶ ⁷. Le résultat est une plateforme optimisée pour des simulations « what-if » rapides : les utilisateurs peuvent créer des scénarios dérivés (comme Git pour les données) et obtenir un retour instantané sur l’impact des changements ⁸. Le système garde toutes les données supply chain en mémoire pour la rapidité, avec des algorithmes ayant un accès direct à la mémoire des données pour un débit maximal ⁹. Cette conception permet une véritable planification concurrente (par exemple, des plans de vente, de production et de stocks mis à jour simultanément en temps réel). D’un point de vue technique, construire un magasin de données personnalisé, en mémoire et avec contrôle de version, est un exploit impressionnant qui offre de l’agilité. L’inconvénient, cependant, est une forte demande matérielle – une approche entièrement en mémoire signifie que le passage à des volumes de données massifs peut s’avérer coûteux (la croissance des besoins en RAM) ¹⁰. Dans l’ensemble, Kinaxis fait preuve d’une forte rigueur technique tant en termes d’architecture que de performance, tout en évitant les revendications à la mode en matière d’IA. Il excelle dans la planification supply et les simulations S&OP, bien qu’il offre moins de fonctionnalités de prévision ML prêtes à l’emploi par rapport à certains concurrents.
SAS – Puissance statistique. SAS est une entreprise de logiciels d’analytics chevronnée (fondée 1976) et apporte un formidable moteur de modélisation statistique aux problèmes de supply chain. Son produit-phare inclut un langage spécifique aux statistiques (le langage SAS) datant des années 1970 ¹¹ – sans doute la première plateforme de data science. La force de SAS réside dans la profondeur de ses algorithmes : une vaste bibliothèque de modèles de prévision des séries temporelles, routines d’optimisation, et techniques de machine learning développées sur plusieurs décennies. Elle emploie certains des ingénieurs et statisticiens les plus talentueux de l’industrie ¹¹, et a été pionnière dans les prévisions avancées bien avant que “AI” ne devienne un mot à la mode. Dans le contexte de la supply chain, SAS est souvent utilisé pour la prévision de la demande et l’analyse des stocks. Techniquement, il est robuste et éprouvé – mais aussi lourd. Les outils peuvent sembler ésotériques (le monde est largement passé à des langages open-source comme Python/R, et en effet, les notebooks Jupyter sont désormais une alternative open supérieure ¹²). SAS ne fait pas de revendications tapageuses sur une IA magique ; il s’appuie sur sa réputation et sa technologie solide. Pour les organisations disposant de l’expertise nécessaire pour l’exploiter, SAS offre une véritable puissance analytique fondée sur des algorithmes réels (ARIMA, ETS, etc.) plutôt que sur le battage médiatique. Son principal inconvénient est qu’il s’agit d’une plateforme d’analytics générale – extrêmement puissante en coulisses, mais qui nécessite des utilisateurs qualifiés pour l’appliquer à la supply chain, et n’a pas été spécifiquement évaluée dans les récentes compétitions de prévision (les outils open-source rivalisent souvent avec lui ¹³).
Dassault Systèmes (Quintiq) – Spécialiste de l’optimisation. Quintiq (acquis par Dassault Systèmes en 2014) est une plateforme résolument axée sur l’optimisation et la planification de la supply chain complexe. Elle propose un langage spécifique propriétaire appelé Quill pour modéliser les contraintes métier ¹⁴. Ce DSL permet aux ingénieurs de coder des solutions sur mesure (par exemple, des plannings de production personnalisés ou des plans d’acheminement) et de tirer parti des solveurs mathématiques. L’existence même d’un DSL dans le produit témoigne d’une compétence deep-tech sérieuse – concevoir un langage de programmation pour les problèmes de planification n’est pas trivial ¹⁵. Quintiq excelle dans des scénarios tels que la planification d’usine, l’optimization des réseaux logistiques, et d’autres problèmes NP-difficiles nécessitant un modèle d’optimisation personnalisé. Techniquement, c’est l’un des moteurs d’optimisation les plus flexibles et puissants disponibles dans les logiciels de supply chain. Cependant, l’accent mis par Quintiq sur l’optimisation se fait au détriment d’autres domaines : par exemple, il possède des capacités de prévision natives relativement limitées ¹⁶. Un autre problème est que les mises à jour techniques publiques sur Quill sont rares, ce qui laisse entendre que la technologie pourrait vieillir ou du moins ne pas évoluer rapidement ¹⁷. Les utilisateurs s’appuient souvent sur les consultants de Dassault pour configurer les solutions, et sans documentation publique claire, il est difficile d’apprécier les innovations récentes. En résumé, Quintiq est un choix de premier ordre pour des besoins d’optimisation complexes et démontre une forte ingénierie grâce à son DSL – mais il n’est pas aussi transparent ou à jour dans des domaines tels que l’IA/la prévision, et ses points forts résident dans ce que les implémenteurs en construisent plutôt que dans une “intelligence” prête à l’emploi.
ToolsGroup (SO99+) – Pionnier probabiliste avec réserves. Le logiciel de ToolsGroup (SO99+) s’est longtemps spécialisé dans la prévision de la demande et l’optimisation de stocks, avec une mise en avant des modèles probabilistes. Il offre une fonctionnalité étendue de supply chain (planification de la demande, réapprovisionnement, optimisation multi-niveaux des stocks) et fut l’un des premiers fournisseurs à vanter la prévision probabiliste “Powerfully Simple”. Sur le papier, cela paraît avancé – ToolsGroup affirme modéliser l’incertitude de la demande et ajuster automatiquement les prévisions, ce qui devrait permettre des cibles de stocks plus précises. Cependant, une analyse technique approfondie soulève des inquiétudes. Les documents publics de ToolsGroup laissent toujours penser qu’ils utilisent des modèles de prévision datant d’avant 2000 en interne ¹⁸ – ils ont ajouté une touche d’“AI” dans leur marketing, mais sans détails. De manière révélatrice, depuis 2018 ils annoncent des prévisions probabilistes tout en se vantant simultanément d’améliorations de MAPE ¹⁹. Il s’agit d’une contradiction flagrante : si les prévisions sont de véritables distributions probabilistes, des indicateurs comme le MAPE (qui mesure la précision sur une valeur unique) ne s’appliquent plus directement ¹⁹. De telles incohérences suggèrent que la partie “probabiliste” pourrait être superficielle ou qu’ils se conforment à d’anciens indicateurs malgré de nouvelles méthodes. De plus, ToolsGroup a usé de termes à la mode tels que “demand sensing AI,” mais ces affirmations sont non étayées par la littérature scientifique ou par un benchmark connu ²⁰. En pratique, de nombreux déploiements de ToolsGroup fonctionnent encore comme des systèmes automatisés basés sur des règles avec des alertes d’exception. En fin de compte : ToolsGroup dispose d’une fonctionnalité étendue et a été précurseur dans la modélisation de l’incertitude, mais son manque de transparence quant aux algorithmes et l’écart entre le marketing et la réalité en matière d’AI/ML font de sa crédibilité technique un atout modéré. C’est un outil solide, axé sur le domaine, mais pas clairement à la pointe de la technologie selon les standards actuels.
Slimstock (Slim4) – Simple et solide. Slimstock est une exception rafraîchissante qui ne suit pas les tendances. Son logiciel Slim4 se concentre sur les techniques de supply chain grand public – telles que les calculs classiques de sécurité des stocks, les points de commande, la quantité économique de commande (EOQ), etc. ²¹. En d’autres termes, Slimstock s’en tient à des méthodes bien établies et éprouvées, enseignées dans les manuels. Bien que cela signifie aucune IA/ML sophistiquée ni algorithmes de pointe, cela rend également Slim4 fiable et facile à comprendre. Le fournisseur évite explicitement les revendications vagues sur l’IA et met plutôt l’accent sur des fonctionnalités pratiques en adéquation avec les besoins quotidiens de la supply chain. Cette honnêteté constitue un atout technique : les utilisateurs savent exactement ce qu’ils obtiennent, et le comportement du système est prévisible. Bien sûr, être simple peut aussi représenter une limitation – vous n’obtiendrez pas de prévisions de demande probabilistes ni d’optimiseurs avancés avec Slim4. Il n’est pas conçu pour des réseaux très complexes ou des volumes de données massifs (et en effet, son architecture technique est probablement une base de données standard avec mise en cache en mémoire, adaptée aux problèmes de taille moyenne). Mais pour de nombreuses entreprises, la simplicité est préférable si cela signifie que l’outil fonctionne de manière constante. Slimstock gagne des points de crédibilité pour avoir évité le jargon, son « directe » approche est saluée par les pairs en contraste avec la posture IA d’autres ²². En résumé, Slim4 n’est pas à la pointe de la technologie, mais c’est un choix judicieux pour la prévision fondamentale et la gestion de stocks avec un battage minimal et une architecture claire à faible risque.
o9 Solutions – Machine à Battage High-Tech. o9 se présente comme un “Digital Brain” pour la supply chain d’entreprise, combinant prévision de la demande, planification supply, S&OP, et même gestion des revenus sur une seule plateforme. Techniquement, o9 a intégré de nombreux concepts technologiques modernes dans son produit : un modèle de données en mémoire, une base de données graphique appelée “Enterprise Knowledge Graph (EKG)”, et divers composants AI/ML. La simple “masse technologique” d’o9 est hors normes ²³ – selon les standards des logiciels d’entreprise, c’est une architecture très ambitieuse qui tente d’unifier toutes les données et analyses de planification. Cependant, un regard sceptique révèle que beaucoup de cela semble être de la technologie pour le simple effet de la technologie, sans véritable retour sur investissement. La conception en mémoire d’o9 garantit des coûts matériels extrêmement élevés à l’échelle ²⁴, similaire à l’exécution continue d’un gigantesque cube BI. o9 vante son EKG (knowledge graph) comme permettant une prévision supérieure et des insights basés sur l’IA, mais aucune preuve scientifique ou benchmark crédible n’est fourni ²⁴. En fait, bon nombre des revendications tape-à-l’œil d’o9 s’effondrent sous l’examen : l’entreprise parle d’IA partout, pourtant des fragments de leur code visible sur GitHub révèlent des techniques plutôt banales ²⁵. Par exemple, o9 a fait la promotion de fonctionnalités telles que la prévision de la demande par machine-learning et des simulations de “digital twin”, mais elle n’a pas démontré cela dans une compétition publique ou une étude de cas évaluée par des pairs. Sans preuve, nous devons considérer ses revendications concernant l’IA comme du battage marketing. Cela dit, o9 n’est pas sans atouts – c’est une plateforme unifiée (développée en interne, et non pas le résultat d’un amalgame d’acquisitions) et qui peut gérer l’intégration de données à grande échelle. Pour une entreprise prête à investir dans le matériel et à faire face à une courbe d’apprentissage abrupte, o9 offre la flexibilité de construire des modèles de planification complexes. Mais d’un point de vue d’ingénierie, c’est une solution surgénérée : beaucoup de complexité, un retour sur investissement des technologies sophistiquées incertain, et des problèmes potentiels de performance si les données dépassent la capacité de la mémoire. Jusqu’à ce qu’o9 fournisse des preuves concrètes (par exemple, une documentation d’algorithmes ou des résultats de benchmark), sa crédibilité reste discutable.
SAP IBP (Integrated Business Planning) – Complet mais Complexe. SAP’s IBP suite est l’évolution de l’ancien APO de SAP, désormais proposée en tant que solution cloud sur la base de données en mémoire SAP HANA. SAP IBP vise à couvrir l’ensemble du spectre : prévision de la demande, optimisation de stocks, supply planning, planification des ventes & opérations, et plus – le tout étroitement intégré avec l’ERP de SAP. La force de SAP IBP réside dans son étendue : il dispose d’un module pour presque chaque aspect de la planification, souvent avec une fonctionnalité très riche héritée de décennies d’expérience de SAP. Cependant, l’étendue a été acquise par le biais d’acquisitions et de systèmes hérités. SAP a acquis des spécialistes tels que SAF (prévision de la demande), SmartOps (optimisation de stocks) et d’autres ²⁶ et les a superposés sur ses outils internes (comme APO et HANA). Le résultat en coulisse est un patchwork de différents moteurs et approches ²⁶. Par conséquent, l’architecture technique d’IBP n’est pas élégante – c’est un ensemble de composants qui ne se combinent pas naturellement, nécessitant un effort d’intégration considérable. Même la documentation de SAP reconnaît la haute complexité et la nécessité de faire appel à des intégrateurs de systèmes de premier ordre (et un temps conséquent) pour que tout fonctionne sans accroc ²⁷. Sur le plan technologique, IBP s’appuie fortement sur SAP HANA, une base de données en mémoire en colonnes, pour atteindre des performances en temps réel. HANA est en effet rapide, mais elle est également coûteuse – stocker de grandes quantités de données de planification uniquement en RAM est intrinsèquement onéreux (la RAM coûte environ 100 fois plus par TB que le stockage sur disque) ¹⁰. Cela signifie que faire évoluer IBP pour des ensembles de données supply chain très volumineux entraîne des coûts d’infrastructure significatifs, et si les données dépassent la mémoire, les performances peuvent chuter brutalement. SAP a commencé à ajouter quelques fonctionnalités de machine learning (par exemple, “Demand Driven MRP” et IBP for Demand dispose de quelques options de prévision ML), mais ce sont principalement des modules complémentaires optionnels avec une transparence limitée. Il n’y a aucune preuve que le ML de SAP soit supérieur aux alternatives ; en fait, aucun algorithme de SAP n’a fait sensation dans des compétitions indépendantes de prévision. En résumé, SAP IBP est riche en fonctionnalités et éprouvé en entreprise – il coche toutes les cases en termes de fonctionnalité – mais d’un point de vue de pureté technique, c’est un mélange hétérogène : rapidité en mémoire mariée à une logique héritée, beaucoup de complexité issue de produits fusionnés, et aucune innovation technique claire en matière de prévision ou d’optimisation au-delà de ce que les éléments acquis faisaient déjà. Les entreprises le choisissent souvent pour son intégration avec l’ERP de SAP plutôt que pour l’excellence en optimisation en soi.
Blue Yonder – Ancien leader devenu patchwork. Blue Yonder (anciennement JDA Software) offre une suite complète couvrant la prévision, la planification de la supply chain, le merchandising et l’exécution. C’est le résultat de nombreuses années de fusions et acquisitions, y compris l’acquisition par JDA d’i2 Technologies (planification de la supply chain), de Manugistics, et de la startup AI Blue Yonder (dont le nom a été adopté) parmi d’autres ²⁸. Malheureusement, les logiciels d’entreprise ne sont pas la simple somme de leurs parties : sous la marque unifiée Blue Yonder se cache un méli-mélo de produits (dont beaucoup sont assez dépassés) assemblés de manière approximative ²⁸. D’un point de vue technique, les solutions de Blue Yonder vont des anciens moteurs de prévision déterministes à des modules d’optimisation de stocks qui n’ont pas fondamentalement changé depuis plus de 15 ans. La société fait largement la promotion des capacités “AI” et “ML” dans sa plateforme Luminate, mais les détails manquent. En fait, les quelques artefacts publics que nous pouvons trouver – tels que des projets open-source et des brevets attribués à l’équipe data science de Blue Yonder – suggèrent qu’ils utilisent des méthodes assez traditionnelles (par exemple, l’extraction de caractéristiques de séries temporelles, des modèles ARMA et de régression linéaire) ²⁹. Ces techniques sont correctes, mais ce sont des approches datant de plusieurs décennies, souvent surpassées aujourd’hui par des méthodes plus récentes. Il semble que l’AI tant vantée de Blue Yonder ne soit peut-être qu’une régression réemballée et des heuristiques. Sans études de cas transparentes ou documents techniques, on doit supposer que les affirmations de Blue Yonder concernant une “prévision AI révolutionnaire” ne sont que du battage marketing. De plus, l’intégration de tous ses composants acquis est un défi constant – de nombreux clients notent des difficultés à obtenir la promesse “end-to-end” parce que les modules (demande, supply, fulfillment, etc.) ne s’imbriquent pas naturellement sans une personnalisation significative. In-memory vs. on-disk? Blue Yonder ne fait pas la promotion d’une architecture entièrement en mémoire comme certains autres ; certaines parties du système fonctionnent probablement sur des bases de données relationnelles standards. Cela pourrait en réalité constituer une bouée de sauvetage en termes de coût, mais cela signifie aussi que les performances peuvent être ralenties à moins que les données ne soient agrégées (par exemple, leurs anciens systèmes utilisaient souvent des exécutions de planification par lots). En résumé, Blue Yonder est une mise en garde : autrefois un leader de l’industrie, il propose désormais une suite vaste mais techniquement incohérente. Ses forces résident dans son expérience du domaine et un ensemble de fonctionnalités étendu, mais ses faiblesses sont une technologie dépassée sous une apparence neuve et l’absence d’évidences crédibles pour ses nouvelles capacités “AI”.

(Note: D’autres fournisseurs tels que Infor (avec des composants legacy GT Nexus et Mercia), GAINS Systems (un autre spécialiste de l’optimisation de stocks), John Galt Solutions (planification de la demande pour le marché intermédiaire), Relex Solutions (prévision de vente au détail avec un moteur en mémoire), etc., existent également. Dans un souci de concentration, nous avons classé ci-dessus les exemples les plus importants ou instructifs. Les mêmes critères sceptiques s’appliquent à ceux qui ne sont pas classés individuellement : par exemple, Relex utilise une conception de type OLAP-cube en mémoire – excellente pour la vitesse, mais garantissant un coût matériel élevé pour les grands détaillants ³⁰ ; Infor s’est développé via des acquisitions menant à des problèmes d’intégration semblables à SAP/Blue Yonder ; GAINS et John Galt offrent une fonctionnalité de base solide mais peu documentée publiquement sur des techniques novatrices. Tout fournisseur ne partageant pas ouvertement des détails techniques ou preuves serait de toute manière classé bas selon la méthodologie de cette étude.)

Analyse Technique Approfondie

Dans cette section, nous approfondissons certains aspects techniques spécifiques des meilleurs logiciels d’optimisation de la supply chain, en nous concentrant sur quatre domaines clés : Prévisions & AI, capacités d’automatisation, architecture système et intégration des modules. Toute l’analyse est basée sur des informations techniques publiées ou des preuves concrètes, en évitant explicitement tout langage marketing.

Capacités de Prévisions & AI

La planification moderne de la supply chain repose sur la précision des prévisions de la demande, cependant les affirmations de supériorité en prévisions sont omniprésentes et souvent infondées.

Performance prouvée vs. battage médiatique : Parmi tous les fournisseurs, Lokad est le seul à disposer d’un palmarès de prévisions de classe mondiale vérifiable, grâce à la compétition M5 open. Lokad a démontré sa maîtrise des prévisions probabilistes en se classant en tête pour la précision au niveau des SKU ¹. Cela crédibilise les affirmations de Lokad en matière de meilleure précision de prévisions. En contraste frappant, aucun autre fournisseur n’a publié de résultats comparables sur une référence indépendante. Par exemple, certains fournisseurs font la promotion d’algorithmes propriétaires (l’un d’eux appelle sa méthode “Procast”) en réclamant une précision supérieure, pourtant ces méthodes étaient absentes des premières places de la compétition M5 ³¹. En pratique, les approches open-source académiques (comme les packages R de prévision du Prof. Rob Hyndman) sont probablement aussi bonnes, voire meilleures, que la plupart des moteurs propriétaires fermés ¹³. Par conséquent, toute affirmation d’un fournisseur de « la meilleure précision de prévision de l’industrie » sans preuve publique doit être considérée comme non étayée.
Affirmations concernant l’AI et le Machine Learning : Nous avons appliqué un scepticisme extrême aux battages médiatiques sur l’AI/ML. Des fournisseurs tels que o9 Solutions et Blue Yonder utilisent abondamment des termes comme « prévisions pilotées par AI/ML » dans leurs brochures. Cependant, en cherchant du concret, nous avons trouvé peu de substance. Dans le cas d’o9, leurs affirmations selon lesquelles le « Enterprise Knowledge Graph » basé sur des graphes produirait de meilleures prévisions sont douteuses et sans appui scientifique ²⁴. Blue Yonder vante de manière similaire l’AI mais ne fournit aucun détail – le seul aperçu de leur technologie provient de quelques dépôts open-source qui montrent l’utilisation de techniques assez ordinaires de séries temporelles (ARMA, régression linéaire, ingénierie des caractéristiques) ²⁹. Il n’existe aucune preuve d’utilisation de deep learning, de méthodes probabilistes avancées ou d’autres AI modernes qui justifieraient leur marketing. ToolsGroup a intégré des concepts de machine learning (ils parlent de « demand sensing » utilisant le machine learning), mais encore une fois aucune étude évaluée par des pairs ou victoire dans une compétition pour le valider ²⁰. En fait, l’association par ToolsGroup de « prévisions probabilistes » avec d’anciennes métriques telles que MAPE suggère que leur AI relève plus du battage que d’une véritable percée ¹⁹. Conclusion : En dehors de Lokad (et dans une certaine mesure SAS, qui utilise des modèles statistiques éprouvés), les prévisions dans la plupart des logiciels de supply chain restent basées sur des méthodes connues (lissage exponentiel, régression, peut-être certains ML basés sur des arbres) et non sur une AI de génie propriétaire. Les fournisseurs possédant des algorithmes véritablement innovants les démontreraient publiquement. L’absence de validation indépendante est révélatrice.
Approches probabilistes vs déterministes : Un différenciateur technique notable est de savoir si un fournisseur adopte la prévision probabiliste (prédire une distribution complète des résultats de la demande) ou se contente de prévisions ponctuelles. Lokad est un fervent défenseur des distributions de probabilité complètes depuis 2012, et en effet, il optimise les décisions (comme les niveaux de stocks) directement à partir des prévisions probabilistes. ToolsGroup prétend également produire des prévisions probabilistes (probablement via des simulations Monte Carlo de la demande). Cependant, nous avons constaté que de nombreux fournisseurs qui affirment être probabilistes se replient en interne sur des métriques et processus déterministes. Par exemple, le marketing de ToolsGroup concernant la réduction du MAPE en utilisant des modèles probabilistes est incohérent, puisque le MAPE ne peut même pas être calculé sur une sortie de prévision probabiliste ¹⁹. Cela suggère que leur processus retombe finalement sur une prévision ponctuelle (moyenne ou médiane) pour l’évaluation, compromettant ainsi l’avantage probabiliste. D’autres fournisseurs comme SAP, Oracle, Blue Yonder ont commencé à mentionner des termes probabilistes (SAP IBP dispose désormais d’« ensembles statistiques » et d’intervalles de confiance), mais leurs interfaces et rapports se limitent souvent à des prévisions à un seul chiffre avec des métriques d’erreur traditionnelles. Adopter une véritable prévision probabiliste nécessite de repenser les KPIs (en utilisant le Pinball loss, le CRPS ou l’atteinte du taux de service au lieu du MAPE). Nous n’avons trouvé aucune preuve qu’un grand fournisseur, hormis Lokad, soit allé aussi loin en pratique. En résumé, la prévision probabiliste est un domaine où le marketing est en avance sur la réalité pour la plupart des fournisseurs – ils peuvent générer quelques distributions en coulisses, mais les planificateurs se contentent toujours de chiffres de prévision ponctuels et de KPI classiques, ce qui indique une adoption limitée du paradigme.
Métriques et évaluation des prévisions : Un aspect important de la rigueur technique est la manière dont un fournisseur évalue la qualité de ses prévisions. Un signal d’alarme est la dépendance continue à des métriques telles que le MAPE, le WAPE ou le biais comme seules mesures de succès, surtout si le fournisseur prétend utiliser l’AI ou des méthodes probabilistes. Cela s’explique par le fait que ces métriques encouragent des prévisions prudentes et « dans les clous », et peuvent être manipulées (par exemple, en supprimant les valeurs extrêmes). Nous avons observé que les fournisseurs dotés de prévisions véritablement avancées tendent à parler de taux de service ou de résultats commerciaux (par exemple, la probabilité de rupture de stock, l’impact sur les coûts) plutôt que de simplement MAPE. Lokad, par exemple, met l’accent sur la réduction des « erreurs en dollars » et l’alignement des prévisions avec l’optimisation des décisions ³². En revanche, ToolsGroup, Blue Yonder et bien d’autres mettent encore en avant des erreurs en pourcentage dans leurs études de cas, montrant un état d’esprit dépassé. Si une documentation ou une démo d’un fournisseur présente de manière trop prononcée des tableaux de bord MAPE/WAPE, cela indique que ses prévisions sont probablement traditionnelles. En effet, l’incohérence de ToolsGroup concernant le MAPE avait déjà été notée ¹⁹. En bref : des prévisions véritablement de pointe en supply chain seraient attestées par des métriques probabilistes et une validation en conditions réelles – des attributs qui manquent en dehors d’un ou deux acteurs.

Capacités d’Automatisation & de Workflow

Atteindre l’optimisation de la supply chain ne se résume pas aux algorithmes ; il s’agit également de la mesure dans laquelle le logiciel peut exécuter le processus de planification de manière entièrement automatisée et sans intervention manuelle. Nous avons examiné les affirmations et la documentation de chaque fournisseur à la recherche d’éléments prouvant l’automatisation, l’intégration par API et le support à la prise de décision autonome.

Lokad : L’automatisation est l’un des piliers de Lokad. L’ensemble de la solution repose sur un langage spécifique au domaine (Envision) qui permet aux planificateurs de supply chain d’encoder leur logique et leurs décisions dans des scripts, lesquels s’exécutent automatiquement selon un planning. Lokad documente clairement ses pipelines de données et son gestionnaire de workflow qui rafraîchit les données et recalcule les décisions (prévisions, propositions de commandes de réapprovisionnement, etc.) sans intervention manuelle ³³ ³⁴. Ils évoquent même la présence de configurations « hautement automatisées » pour environ 100 supply chains en production ³⁴, ce qui signifie que le logiciel récupère des données, réalise des prévisions et génère des décisions (comme des propositions de commandes d’achat) de manière totalement automatisée. De plus, Lokad fournit des API pour le téléchargement des données et l’extraction des résultats, et propose un concept « AI Pilot » pour automatiser les tâches administratives ³⁵. Tout cela indique un niveau très élevé d’automatisation réelle – le rôle de l’utilisateur consiste principalement à surveiller et affiner le code/les paramètres, et non à appuyer manuellement sur des boutons pour chaque plan. L’approche de Lokad en matière d’automatisation est crédible et techniquement détaillée (ils ont même donné des conférences sur la transition des décisions manuelles vers des décisions automatisées ³⁶ ³⁷).
Kinaxis: Kinaxis RapidResponse est conçu pour l’analyse rapide de scénarios et pour la collaboration plutôt que pour la planification entièrement automatisée. Le concept de « planification concurrente » consiste à ce que tout le monde travaille sur le même ensemble de données avec des mises à jour en temps réel, mais il implique généralement que des planificateurs humains évaluent les scénarios et prennent des décisions. Cela dit, Kinaxis prend en charge l’automatisation de certaines manières : il peut ingérer des données provenant de systèmes ERP en quasi temps réel, exécuter en continu ses algorithmes d’appariement offre/demande et déclencher des alertes ou des messages d’exception aux utilisateurs lorsque les choses dépassent les limites. Il expose des fonctionnalités via des API et propose du scripting (sous forme d’algorithmes configurables et de macros dans son environnement) pour les utilisateurs experts. Cependant, Kinaxis se positionne généralement comme un outil d’aide à la décision, et non comme une boîte noire qui libère automatiquement les commandes. Le fournisseur ne clame pas haut et fort « supply chain autonome » ; il se concentre plutôt sur l’amélioration de l’efficacité des planificateurs. C’est une position honnête. Cela signifie que par défaut, RapidResponse attend toujours la présence d’humains dans la boucle – ce qui peut constituer une limitation si l’on recherche un système de supply chain « autonome ». Techniquement, Kinaxis peut être intégré en profondeur (par exemple, il s’intègre souvent avec SAP ERP pour exécuter des plans approuvés), mais une opération de bout en bout sans surveillance nécessiterait beaucoup de configuration personnalisée. Nous n’avons trouvé aucune preuve que Kinaxis fournisse des recommandations de décision pilotées par l’IA (sa force réside davantage dans le calcul rapide des scénarios définis par les utilisateurs).
o9 Solutions : o9 fait largement la promotion de concepts tels que le « jumeau numérique » de l’organisation et de l’IA capable de formuler des recommandations. Ils évoquent « l’automatisation » dans le contexte de leurs assistants digitaux – vraisemblablement des bots capables de faire émerger des insights ou d’exécuter certaines tâches. Cependant, en l’absence d’une documentation technique concrète, il est difficile de déterminer ce qui est réel. Nous n’avons pas trouvé de précisions telles que « o9 peut automatiquement déclencher des ordres de réapprovisionnement via API selon ses plans » ou « o9 utilise l’apprentissage par renforcement pour ajuster ses paramètres de manière autonome ». L’ambiguïté de l’histoire d’automatisation d’o9 est préoccupante : beaucoup de discours de haut niveau, peu de détails. Étant donné sa base reposant sur un système en mémoire, nous soupçonnons qu’o9 est capable de mises à jour de données en temps réel ainsi que de recalculs, mais qu’il dépend probablement toujours des utilisateurs pour configurer ce qu’il convient de faire avec ces informations. Sans références crédibles, nous traitons les affirmations d’« autonomie » d’o9 comme non vérifiées. Il est possible d’intégrer o9 via des API dans des systèmes d’exécution (c’est un logiciel moderne, donc l’intégration API devrait exister), mais la part de prise de décision réellement automatisée par l’IA dans o9 reste floue. Les éléments laissent penser que l’automatisation actuelle d’o9 consiste davantage à accélérer l’analyse (par exemple, des scénarios instantanés de simulation) qu’à automatiser les résultats décisionnels.
Blue Yonder : Ces dernières années, Blue Yonder (en particulier depuis son acquisition par Panasonic) a valorisé le terme « supply chain autonome », sous-entendant un système capable de fonctionner avec une intervention humaine minimale. Ils disposent de certains composants, comme Luminate Control Tower, qui utilisent l’IA pour détecter des perturbations et éventuellement déclencher des réponses. Cependant, compte tenu de leur cœur hérité, il est probable que toute autonomie soit obtenue en superposant de la RPA (Automatisation des Processus Robotiques) ou de simples agents d’IA sur des modules existants. Par exemple, la planification de la demande chez Blue Yonder pourrait produire une prévision, et une couche « IA » pourrait l’ajuster automatiquement sur la base de ventes en temps réel (détection de la demande) ou envoyer une alerte en cas d’écart. Mais la planification entièrement automatisée (comme la délivrance automatique des commandes, l’ajustement automatique des politiques de stocks) est probablement rare dans les solutions BY – les clients font généralement encore réviser et approuver les actions par des planificateurs. Le manque de littérature technique détaillée sur la manière dont Blue Yonder automatise les décisions est révélateur. S’ils disposaient d’un planificateur véritablement autonome, ils publieraient des cas de succès ou des billets techniques à ce sujet. Au lieu de cela, ils se contentent surtout de webinaires marketing. Nous en déduisons donc que Blue Yonder permet un certain degré d’automatisation (comme des traitements par lots, des mises à jour de plans, peut-être une intégration en boucle fermée aux systèmes d’exécution), mais qu’il n’est pas démontré comme étant en avance dans ce domaine. Il utilise vraisemblablement une planification basée sur la gestion des exceptions similaire à celle des systèmes plus anciens (simplement avec un vernis IA sur le système d’alerte).
ToolsGroup : Historiquement, ToolsGroup s’est vanté de « l’automatisation puissamment simple ». Ils affirmaient que leur système pouvait fonctionner en mode sans surveillance pendant de longues périodes, n’invoquant les planificateurs qu’en cas d’exception. En effet, la philosophie de ToolsGroup était de laisser le système recalculer automatiquement les prévisions et replanifier quotidiennement, en s’adaptant aux nouvelles données. À leur actif, de nombreux clients de ToolsGroup ont constaté une réduction de la charge de travail des planificateurs parce que le logiciel ajuste lui-même les objectifs de stocks et recommande automatiquement des commandes. ToolsGroup dispose également d’une boîte à outils d’intégration pour transmettre les commandes approuvées aux systèmes ERP. Cependant, en raison des contradictions relevées précédemment, nous avons des doutes quant à l’intelligence de cette automatisation. Il se peut qu’il applique simplement la même formule chaque jour et signale les anomalies (gestion des exceptions). ToolsGroup fournit une API et prend en charge des exécutions programmées, donc techniquement, l’infrastructure pour l’automatisation est présente. La question porte sur la qualité des décisions automatisées. Ils mentionnent souvent le « self-tuning » – ce qui implique que le logiciel ajuste lui-même les paramètres du modèle de prévision au fur et à mesure que de nouvelles données arrivent ³⁸. Si tel est le cas, cela constitue une automatisation utile (supprimant le besoin d’une reconfiguration humaine constante). Sans évaluation indépendante, nous pouvons dire avec prudence que ToolsGroup offre une haute automatisation dans les tâches de planification de routine, mais le manque de transparence rend difficile de juger à quel point cette automatisation est « intelligente » (par exemple, apprend-elle réellement et s’améliore-t-elle ou se contente-t-elle de suivre des règles prédéfinies ?).
Autres fournisseurs : La plupart des autres acteurs prennent en charge des capacités d’automatisation standards : intégration de données via API ou traitement par lots de fichiers, exécutions programmées de planification et certains workflows basés sur des exceptions. Par exemple, SAP IBP peut être configuré pour lancer automatiquement une tâche de prévision chaque mois et alimenter les résultats de planification, mais typiquement un planificateur vérifie le résultat. Anaplan est moins axé sur l’automatisation – c’est plutôt une plateforme de modélisation manuelle, bien que vous puissiez utiliser son API pour envoyer/recevoir des données et peut-être automatiser certains calculs. Dassault/Quintiq peut être scripté pour exécuter des routines d’optimisation selon un calendrier (et le DSL de Quintiq permet de programmer des comportements automatiques personnalisés), mais là encore, l’autonomie n’est que celle programmée par l’implémenteur. GAINS, Relex, Netstock et d’autres fournisseurs de niche vantent « l’automatisation de bout en bout » dans le réapprovisionnement – signifiant généralement qu’ils peuvent générer automatiquement des commandes d’achat ou des recommandations de transfert en magasin. La différence clé réside dans le niveau de supervision requis : un véritable système de planification autonome n’appellerait les humains qu’en cas de situations inhabituelles et documenterait ses décisions avec des justifications. Nous n’avons trouvé aucun fournisseur qui atteigne pleinement cet idéal à ce jour. Ils exigent soit que les humains ajustent et approuvent (dans la plupart des cas), soit ils automatisent uniquement les décisions les plus simples et laissent le reste.

Résumé de l’automatisation : Seuls quelques fournisseurs (notamment Lokad) détaillent publiquement un cadre d’automatisation permettant des cycles de planification sans surveillance et pilotés par API. D’autres disposent des moyens techniques pour l’automatisation, mais dépendent toujours des humains pour finaliser le processus. Nous notons également que certains fournisseurs ont, ces dernières décennies, déplacé leur focus de l’automatisation complète vers la « gestion des exceptions » – qui est essentiellement une approche semi-automatisée où le logiciel fait ce qu’il peut et signale le reste aux humains ³⁷. Cette approche, bien que pratique, peut constituer une béquille pour un logiciel qui n’est pas suffisamment robuste pour être totalement fiable. Notre point de vue sceptique est le suivant : si un fournisseur ne peut pas expliquer comment il automatise les décisions (quels algorithmes, quels déclencheurs, quels appels API), alors son « automatisation » se résume probablement à du discours marketing.

Architecture du système & scalabilité

L’architecture sous le capot – notamment l’utilisation du calcul en mémoire par rapport au stockage sur disque, ainsi que les choix de conception globaux – a d’énormes implications sur la scalabilité, le coût et la performance d’un logiciel de supply chain. Nous avons examiné la pile technologique centrale de chaque fournisseur en nous concentrant sur la manière dont ils gèrent de grandes quantités de données et des calculs complexes.

Calcul en mémoire – Avantages et Inconvénients : Plusieurs des principaux fournisseurs reposent sur une architecture en mémoire, ce qui signifie que le logiciel charge la plupart ou la totalité des données pertinentes dans la RAM pour un accès rapide lors des calculs. Cela inclut Kinaxis, Anaplan, o9, SAP HANA (IBP), Relex et possiblement Quintiq (pour la résolution de scénarios). L’avantage est la vitesse : l’accès à la RAM est de plusieurs ordres de grandeur plus rapide que l’accès au disque. Par exemple, le moteur de Kinaxis charge toutes les données en mémoire pour permettre un recalcul instantané des scénarios et des opérations algorithmiques directes sur l’ensemble de données ⁹. HANA de SAP a été conçu sur le principe que l’analyse des données en direct devait se faire en mémoire pour obtenir des résultats en temps réel ³⁹ ⁴⁰. Cependant, il existe un problème fondamental avec une conception entièrement basée sur la mémoire : le coût et la scalabilité. La mémoire (RAM) est extrêmement coûteuse par rapport au stockage. 1 To de RAM peut coûter 100 fois plus cher que 1 To de disque ¹⁰. Et la capacité mémoire des serveurs est limitée physiquement (les systèmes typiques peuvent avoir de 0,5 à 2 To de RAM au maximum, alors que des ensembles de données de plusieurs téraoctets ou pétaoctets sont courants dans les grandes supply chains). Ces dernières années, les baisses drastiques attendues du coût de la RAM ne se sont pas matérialisées – les prix et capacités de la RAM sont restés relativement stagnants ⁴¹. Cela signifie que tout système exigeant le chargement de toutes les données en mémoire sera confronté à des coûts d’infrastructure exponentiels à mesure que les données augmentent, ou atteindra une limite physique où il ne pourra tout simplement pas contenir les données. Nous qualifions une forte dépendance à une conception en mémoire de gaffe architecturale pour les grandes supply chains, à moins que des mesures d’atténuation ne soient mises en place.
Mémoire vs. Disque : Pratiques Modernes : Fait intéressant, le monde technologique a réalisé que les solutions purement in-memory ne représentent pas l’avenir pour le big data. Les architectures plus récentes utilisent une approche en plusieurs niveaux – garder les données chaudes en mémoire et les données froides sur SSD, etc. ⁴² ⁴³. Certains logiciels de supply chain ont commencé à adopter cette méthode. Par exemple, Lokad utilise explicitement des techniques de « spill to disk » dans son infrastructure cloud. Leur CTO a expliqué comment ils gèrent un ensemble de données retail de 10 milliards de lignes en utilisant environ 37 Go de RAM, complétés par un SSD NVMe rapide pour déverser l’excès ⁴⁴ ³. Ils atteignent des performances proches de celles de la RAM en mappant les fichiers en mémoire et en ne conservant en RAM que les données les plus sollicitées, le logiciel effectuant intelligemment des échanges au besoin ⁴⁵ ⁴⁶. Cette approche permet d’énormes économies – par exemple, pour le coût de 18 Go de RAM haut de gamme, on peut acheter 1 To de SSD NVMe ³, soit 50 fois moins cher par octet tout en étant seulement environ 6 fois plus lent en accès brut, un compromis souvent avantageux. Aucun des fournisseurs centrés sur l’in-memory (Kinaxis, SAP, o9, etc.) n’a décrit publiquement une telle gestion adaptative de la mémoire, ce qui suggère que leurs solutions pourraient simplement exiger beaucoup de RAM ou nécessiter une agrégation des données pour tenir. Anaplan est connu pour rencontrer des limites de taille de modèle – certains clients atteignent les limites de mémoire de son Hyperblock et doivent scinder leurs modèles. Kinaxis nécessite probablement également plusieurs serveurs interconnectés pour traiter de très grandes quantités de données (ils évoquent un concept de répartition des données, mais au sein de chaque nœud celles-ci résident en mémoire). SAP HANA peut décharger sur disque (il dispose de nœuds d’extension), mais les performances en pâtissent. En résumé : une conception rigide en mémoire est un signal d’alarme pour la scalabilité. Elle peut fonctionner brillamment pour de petites à moyennes quantités de données, mais à mesure que la supply chain se développe (pensez à une planification détaillée au niveau SKU-magasin-jour pour un détaillant mondial), les coûts et les risques de performance explosent. L’ingénierie moderne privilégie un mélange d’utilisation de la mémoire et du disque pour équilibrer vitesse et coût, et les fournisseurs ne faisant pas cela accusent du retard.
Pile technologique et Complexité : Au-delà de la mémoire, un autre élément architectural est la pile technologique globale – monolithique versus microservices, utilisation de langages de programmation modernes, etc. Sans entrer dans trop de détails, nous avons observé que les fournisseurs plus anciens (SAP APO/IBP, Blue Yonder) fonctionnent sur des piles monolithiques et héritées, tandis que les plus récents (o9, Anaplan) ont développé leur propre solution à partir de zéro avec des technologies plus modernes. Par exemple, le cœur d’IBP de SAP inclut encore des moteurs des années 2000 (comme l’optimiseur d’APO) désormais enveloppés dans une couche HANA/cloud. Cela introduit de la complexité et une inefficacité potentielle (multiples couches d’abstraction). Blue Yonder dispose également de beaucoup de code hérité datant de l’époque d’i2 et de JDA. Kinaxis est quelque peu unique – il est ancien (commencé dans les années 90) mais ils ont continuellement refondu leur propre noyau de base de données ; néanmoins, c’est une pile propriétaire qu’eux seuls utilisent. Anaplan a construit un moteur de calcul très efficace (en Java) pour son cas d’utilisation spécifique (Hyperblock), et il est assez optimisé pour cet usage – mais il n’est pas ouvert, et il faut vivre avec ses contraintes (par exemple, pas de requêtes SQL, une complexité algorithmique limitée puisqu’il s’agit principalement de calculs au niveau des cellules). La plateforme d’o9 inclut un mélange de technologies (probablement une base de données NoSQL/graph, peut-être Spark ou autre pour du ML, etc.), ce qui la rend complexe mais théoriquement flexible.
Matériel et Cloud : Une tendance notable est la conception native pour le cloud. De nombreux fournisseurs proposent désormais leur logiciel en mode SaaS ou du moins hébergé sur le cloud, mais tous ne sont pas véritablement cloud-native. Par exemple, Anaplan et o9 sont des SaaS multi-locataires (conçus pour le cloud dès le départ). Lokad est nativement cloud (il fonctionne sur Microsoft Azure et alloue des ressources de manière dynamique). SAP IBP est hébergé sur le cloud, mais chaque client constitue essentiellement une instance isolée sur HANA (non multi-locataire au sens strict). ToolsGroup, Blue Yonder proposent des offres SaaS, mais souvent il s’agit simplement de leur logiciel sur site, géré par eux dans le cloud. Pourquoi cela est-il important d’un point de vue technique ? Les architectures cloud-native sont généralement plus élastiques – elles peuvent mobiliser des ressources de calcul quand cela est nécessaire (pour une importante exécution de planification) puis les désactiver ensuite, contrôlant ainsi les coûts. Les systèmes non cloud exigent souvent l’achat de capacité maximale, même s’ils ne sont utilisés qu’occasionnellement. De plus, les systèmes cloud-native s’intègrent souvent mieux à d’autres services cloud (par exemple, se brancher sur un service ML cloud ou un data lake). D’après nos observations, les solutions les plus cloud-native et conçues pour être scalables semblent être Lokad et o9 (et peut-être Anaplan), tandis que d’autres rattrapent leur retard. Cependant, être cloud-native à lui seul n’égale pas une bonne architecture – o9 est cloud-native, mais nous avons remis en question son approche fortement basée sur la mémoire ; le fait que SAP IBP soit sur cloud n’élimine pas ses problèmes de complexité.
Concurrence et Besoins en Temps Réel : Une considération architecturale est de savoir comment le système gère les utilisateurs simultanés et les mises à jour en temps réel. Kinaxis brille ici : il a été conçu pour permettre à plusieurs planificateurs de réaliser de la planification de scénarios simultanément sur le même jeu de données. Cela requiert une gestion minutieuse des versions de données et une logique de verrouillage – que Kinaxis a obtenue grâce à son mécanisme de branchement ⁸. La plupart des autres outils suivaient traditionnellement un paradigme par lots (planifier, publier, puis collaborer séparément). Désormais, beaucoup ajoutent des fonctionnalités de planification simultanée. Anaplan permet à plusieurs personnes de travailler dans différentes parties du modèle en même temps (puisqu’il est essentiellement basé sur des cellules, comme Google Sheets). SAP IBP a introduit une interface « semblable à Microsoft Excel » qui peut rafraîchir les données depuis le serveur à la demande, mais la véritable concurrence (plusieurs utilisateurs éditant simultanément le même plan) est limitée. o9 supporte vraisemblablement un certain niveau de concurrence étant donné son graphe de connaissances (plusieurs utilisateurs peuvent ajuster différents nœuds). Lorsqu’on évalue le mérite technique, un système capable de fonctionner véritablement en temps réel avec de nombreux utilisateurs indique une architecture robuste. Kinaxis et Anaplan obtiennent des points ici. Ce n’est pas que d’autres ne puissent pas le faire, mais souvent leurs anciennes architectures le rendent difficile – ce qui entraîne soit des performances lentes, soit l’obligation de processus séquentiels.

Résumé de l’Architecture : Nous avons identifié un schéma : les conceptions centrées sur la mémoire (Kinaxis, Anaplan, o9, Relex, SAP HANA) offrent de la rapidité mais au détriment de la scalabilité et du coût ($$), tandis que les conceptions hybrides (le spill-to-disk de Lokad, peut-être des outils utilisant des bases de données modernes) sont plus scalables et rentables. Un signal d’alarme évident est tout fournisseur insistant sur le fait que tout doit être en RAM pour fonctionner – ce qui est désormais considéré comme une approche dépassée compte tenu des avancées en vitesse des SSD et en informatique distribuée ⁴² ⁴³. Nous soulignons également que l’architecture des fournisseurs issues de multiples acquisitions (comme SAP, Blue Yonder) tend à être excessivement complexe et nécessite de nombreux ajustements. Des architectures plus simples, développées en interne (la base de code unique de Kinaxis, le moteur unique d’Anaplan, le moteur unique de Lokad) tendent à être plus cohérentes et donc plus faciles à maintenir techniquement. Lors de l’évaluation d’un logiciel de supply chain, il convient de se demander : Le fournisseur a-t-il publié quelque chose sur la manière dont son logiciel est construit (microservices ? base de données personnalisée ? utilisation de bibliothèques ML ? etc.) Un manque de discussion technique pourrait signifier que l’architecture n’est qu’une boîte noire – indiquant souvent soit une technologie héritée, soit un manque de confiance dans leur singularité.

Intégration & Cohérence des Modules (Impact des F&A)

La planification de la supply chain couvre généralement plusieurs domaines (prévision de la demande, optimisation de stocks, planification de la production, etc.). Certains fournisseurs offrent une suite intégrée construite de manière organique, tandis que d’autres ont grandi par acquisitions, ajoutant de nouveaux modules. Nous avons examiné comment l’ensemble de la solution de chaque fournisseur est intégré et quels signaux d’alarme émergent de leur stratégie de croissance.

Blue Yonder (JDA) est l’exemple type de croissance par acquisition. Comme mentionné, c’est une « collection hasardeuse » de produits issus d’époques différentes ²⁸. JDA a acquis i2 (qui lui-même comportait plusieurs modules), acquis Manugistics plus tôt, puis RedPrairie (pour la gestion des entrepôts), puis la start-up Blue Yonder pour l’IA. Chaque élément avait son propre schéma de base de données et sa propre logique. Le résultat : encore aujourd’hui, la planification de la demande, la planification de l’offre et l’optimisation de stocks chez Blue Yonder pourraient ne pas partager un modèle de données unifié – l’intégration repose sur des interfaces. C’est un signal d’alarme car cela signifie que la mise en œuvre de la suite complète revient essentiellement à intégrer plusieurs logiciels distincts. Lorsque les produits d’un fournisseur ne sont pas véritablement unifiés, les clients rencontrent des problèmes tels que des délais de synchronisation des données, des interfaces utilisateur incohérentes et des fonctionnalités dupliquées. Dans le cas de Blue Yonder, certains de ses modules se chevauchent franchement (après des acquisitions, vous pourriez avoir deux manières de faire la planification de stocks – l’une issue de l’ancien Manugistics et l’autre d’i2). L’entreprise a déployé des efforts pour rationaliser cela, mais ce n’est pas entièrement résolu. En termes techniques, un logiciel d’entreprise ne se “mélange” pas magiquement comme des fluides lorsque des entreprises fusionnent ²⁸ – cela demande des années de réingénierie. Nous n’avons pas vu de preuve que Blue Yonder ait complété cette réingénierie. Ainsi, l’absence de cohérence est une faiblesse technique majeure.
SAP IBP a de même combiné des composants acquis : l’achat par SAP de SAF, SmartOps, et d’autres a apporté des outils séparés que SAP a ensuite intégrés sous l’égide d’IBP ²⁶. Des utilisateurs ont noté qu’IBP possède différents modules qui donnent l’impression d’applications distinctes (par exemple, IBP pour la demande vs. IBP pour les stocks). La logique d’optimisation des stocks de sécurité dans IBP proviendrait probablement de l’acquisition de SmartOps, tandis que la détection de la demande pourrait provenir de SAF ou de développements internes. L’intégration est meilleure que celle de Blue Yonder (SAP a au moins réécrit l’interface utilisateur et mis tout sur la base HANA), mais toujours, en coulisses, IBP n’est pas une base de code unique. SAP avertit explicitement que la mise en œuvre d’IBP nécessite généralement plusieurs années et des intégrateurs experts pour que tous les modules fonctionnent ensemble de manière optimale ²⁷. Cette affirmation est en soi un signal d’alarme – elle implique un décalage potentiel et une complexité.
Infor (bien que n’étant pas dans le top 10 ci-dessus) a également fusionné divers systèmes de planification (ils avaient acquis la planification de la supply chain de Mercia et GT Nexus, etc.). Le résultat n’a jamais été une véritable plateforme de planification unifiée ; Infor tend à se concentrer sur les systèmes d’exécution. C’est donc un autre exemple où l’acquisition n’a pas permis d’obtenir un excellent produit de planification intégré.
Dassault (Quintiq) : Dans ce cas, l’acquisition (par Dassault) n’a pas impliqué de fusionner Quintiq avec un autre outil de planification – Dassault a plus ou moins laissé Quintiq continuer en tant qu’offre autonome axée sur l’optimisation de la production et de la planification. Ainsi, la cohérence interne de Quintiq est bonne (il a été développé en interne et reste tel quel), mais l’inconvénient est qu’il ne couvre pas tous les domaines (par exemple, aucune prévision native de la demande, comme noté ¹⁶). Le portefeuille de Dassault comprend d’autres produits (comme Apriso pour le MES, etc.), mais ils ne sont pas intégrés de manière approfondie avec Quintiq. Donc, en termes d’intégration, Quintiq est auto-cohérent mais fonctionnellement étroit. Du point de vue de l’utilisateur, vous pourriez devoir l’intégrer avec un autre outil de prévision, ce qui implique un travail supplémentaire du côté client.
Kinaxis a surtout connu une croissance organique – il a acquis une petite entreprise d’IA, Rubikloud, en 2020 (pour l’IA dans le retail) et un outil de conception de supply chain (Castle Logistics) en 2022, mais ceux-ci sont relativement récents et il reste à voir comment ils s’intègrent. Historiquement, RapidResponse était un produit unique gérant divers aspects de la planification via configuration. Cette cohérence est un avantage : tous les modules (demande, offre, stocks) partagent une même base de données et une même interface utilisateur chez Kinaxis. De même, Anaplan a développé différentes applications de planification sur une seule plateforme – les plans de vente, de finance et de supply chain résident tous dans le même environnement Hyperblock, ce qui est techniquement très cohérent (seulement des modèles différents). o9 Solutions est également une plateforme unique développée de manière organique qui couvre de nombreux domaines (elle n’a pas grandi en acquérant d’autres fournisseurs de planification, du moins pas des majeurs). Ainsi, ces trois – Kinaxis, Anaplan, o9 – disposent d’un avantage architectural en termes d’unité. La prudence envers eux ne concerne pas l’intégration de modules disparates, mais la capacité de leur plateforme unique à gérer véritablement la profondeur de chaque domaine.
ToolsGroup & Slimstock : Ces fournisseurs sont restés concentrés sur leur niche (planification de la demande et des stocks). Ils n’ont pas réellement acquis d’autres entreprises ; à la place, ils se sont associés ou intégrés avec des systèmes d’exécution au besoin. Cela signifie que leur logiciel est cohérent en interne (une seule base de code), ce qui est positif, mais si un client a besoin de capacités plus larges (comme la planification de la production), il doit utiliser un autre produit et l’intégrer lui-même. Ces dernières années, ToolsGroup a commencé à ajouter des fonctionnalités S&OP et a même acquis une startup d’IA (Eramos en 2018) pour le machine learning, mais encore une fois, ceux-ci ont été intégrés dans le produit principal plutôt que vendus séparément. Ainsi, l’intégration n’est pas un gros problème pour ToolsGroup ou Slimstock – le compromis réside dans le fait de savoir si leur conception à focalisation unique couvre suffisamment l’étendue des besoins de l’utilisateur.

Résumé de l’Intégration : D’un point de vue sceptique, de multiples acquisitions majeures dans l’histoire d’un fournisseur constituent un signe d’avertissement. Cela conduit souvent à un produit touche-à-tout, qui n’est expert en rien, avec une complexité cachée. Blue Yonder et SAP en sont l’exemple – leur complexité technique découle en partie de la tentative de coller ensemble de nombreux éléments hérités. Inversement, les fournisseurs disposant d’une plateforme unifiée (construite de manière organique) évitent ces problèmes, bien qu’ils doivent encore prouver qu’une seule plateforme peut tout faire correctement. Lors de l’évaluation d’un logiciel, il convient de s’interroger sur l’origine de chaque module : si le module de planification de la demande et le module de planification de l’offre proviennent d’entreprises d’origine différentes, examinez comment ils partagent les données et si l’intégration se fait de manière fluide ou via des interfaces. L’histoire a montré que, à moins que la technologie acquise ne soit réécrite de zéro dans une architecture unifiée (ce qui est rare en raison des coûts et du temps), le résultat est généralement un système Frankenstein. Nos recherches confirment cela – les fournisseurs ayant obtenu les meilleures notes en élégance technique (Lokad, Kinaxis, Anaplan) ont construit leurs solutions de manière holistique, tandis que ceux ayant obtenu les notes les plus faibles (Blue Yonder, Infor) ont accumulé des technologies disparates sans les unifier complètement.

Faiblesses Critiques & Signaux d’Alerte

Dans notre revue rigoureuse, nous avons identifié plusieurs faiblesses récurrentes et signaux d’alarme dont les utilisateurs potentiels devraient être conscients. Ci-dessous se trouve un résumé des enjeux clés, avec des exemples de fournisseurs spécifiques pour illustrer chaque point :

Allégations « IA/ML » non étayées : Soyez extrêmement sceptique envers tout fournisseur proclamant une IA ou un machine learning supérieurs sans preuves techniques concrètes. Par exemple, Blue Yonder fait largement la publicité de l’IA mais ne fournit que des affirmations vagues sans substance ²⁹ – ce que nous pouvons observer de leurs méthodes indique qu’ils s’appuient sur des techniques plus anciennes, et non sur une IA de pointe. De même, o9 Solutions vante son IA et son intelligence basée sur les graphes, pourtant l’analyse de leur code public et de leurs documents montre « une tonne de battage médiatique autour de l’IA » avec seulement des analyses banales en réalité ²⁵. Si un fournisseur ne peut pas citer d’études évaluées par des pairs, de brevets, de compétitions ou de documents techniques détaillés pour étayer ses allégations sur l’IA, considérez-le comme du bluff marketing. Les fournisseurs véritablement avancés seront fiers de détailler leurs algorithmes.
Absence d’Étalonnage Concurrentiel (Allégations de Supériorité en Prévision) : De nombreux fournisseurs revendiquent une « précision de prévision de premier ordre » mais aucun, à l’exception de Lokad, ne l’a prouvée en compétitions ouvertes ou dans des publications. Nous considérons toute telle affirmation comme fallacieuse à moins d’être validée. Par exemple, l’algorithme propriétaire d’un fournisseur, vanté comme « plus précis que les autres », était absent des premiers rangs de la compétition M5 ³¹, ce qui suggère fortement que leur affirmation est infondée. En fait, aucun fournisseur traditionnel de logiciels de supply chain (à l’exception de Lokad) n’est apparu dans le top 100 de ce concours mondial de prévision. Cela constitue un signal d’alarme majeur : cela implique que ces fournisseurs n’ont soit pas participé (peut-être pour éviter un embarras public), soit ont participé et obtenu de mauvais résultats. Conseil actionnable : Exigez de voir des résultats objectifs de précision (par exemple, comment leur outil a-t-il performé sur une référence standard telle que le jeu de données M5 ou M4) – s’ils n’en peuvent fournir aucun, ne vous laissez pas séduire par le battage médiatique.
Dépassement de l’Architecture en Mémoire : Les fournisseurs qui prônent une conception entièrement basée sur la mémoire devraient être interrogés sur la scalabilité et le coût. L’informatique en mémoire offre de la rapidité, mais la RAM est environ 100 fois plus chère par Go que le disque ¹⁰ et son rapport prix/performance a stagné ces dernières années ⁴¹. Cela rend les solutions purement en mémoire non scalables et coûteuses pour de grands volumes de données. SAP IBP (HANA) et o9 en sont des exemples : ils garantissent des performances élevées uniquement si vous chargez d’énormes jeux de données en mémoire, ce qui garantit des factures matérielles (ou cloud) élevées ²³ ³⁰. Il est révélateur que la conception des systèmes modernes s’éloigne de cette approche – comme le résume un expert, la frénésie initiale de tout loger en RAM a atteint des limites pratiques, et les bases de données « retrouvent leur amour pour le disque » afin de gérer efficacement les données froides ⁴² ⁴³. Si un fournisseur reste bloqué sur une mentalité exclusivement en mémoire, considérez cela comme un signal d’alarme architectural. Les fournisseurs plus scalables évoqueront le stockage hiérarchisé, l’élasticité du cloud ou des stratégies similaires pour gérer des données à grande échelle sans nécessiter une RAM infinie.
Boîte Noire issue des F&A (Dysfonction d’Intégration) : Si la suite de produits d’un fournisseur résulte de nombreuses acquisitions, méfiez-vous des lacunes d’intégration et des fonctionnalités qui se chevauchent. Comme nous l’avons vu, la suite de Blue Yonder est un mélange hétéroclite de produits datés en raison d’une longue série de fusions ²⁸, et les modules d’IBP de SAP proviennent de différentes entreprises acquises ²⁶, ce qui se traduit par une complexité et une « collection » d’outils plutôt qu’un tout homogène. Les logiciels d’entreprise ne se “mélangent” pas facilement à travers des F&A ²⁸ – à moins que le fournisseur n’ait procédé à une réingénierie complète (ce qui est rare et chronophage), le client se retrouve souvent à jouer le rôle d’intégrateur entre les modules. Cela peut signifier des expériences utilisateur incohérentes, une saisie de données dupliquée et des interfaces fragiles. Symptôme de signal d’alarme : La mise en œuvre par le fournisseur nécessite un bataillon de consultants pendant un an ou plus pour faire communiquer les modules – comme cela a même été reconnu dans le cas de SAP ²⁷. Préférez les fournisseurs disposant d’une plateforme unifiée ou d’un chevauchement minimal dans les composants acquis.
Métriques contradictoires et buzzwords: Un signal subtil mais révélateur se présente lorsqu’une histoire technique d’un fournisseur contient des contradictions internes ou des pratiques obsolètes déguisées sous une nouvelle terminologie. Un exemple flagrant fut ToolsGroup faisant la promotion de prévisions probabilistes tout en faisant simultanément référence à des améliorations de MAPE ¹⁹ – un signe qu’ils se contentent d’ajouter une nouvelle terminologie à de vieilles pratiques (puisqu’utiliser MAPE pour évaluer des prévisions probabilistes est conceptuellement erroné). Un autre exemple est celui des fournisseurs qui prétendent utiliser « advanced AI » mais qui ensuite mesurent leur succès avec de vieilles métriques comme MAPE ou des taux de service traditionnels – cela indique qu’ils n’ont pas véritablement adopté le nouveau paradigme. De même, attention aux méthodologies de stock de sécurité : un fournisseur peut prétendre optimiser ses stocks avec AI, mais si vous explorez et découvrez qu’il calcule encore le stock de sécurité à l’aide d’une formule des années 1980 (par ex. une hypothèse de distribution normale avec un facteur de sécurité statique), c’est une contradiction. Nous avons en effet trouvé des cas où des fournisseurs parlent de stock « probabiliste » ou « optimal », alors que leur documentation révèle des calculs standards de stock de sécurité et l’utilisation de métriques obsolètes comme le fill rate. Conclusion : Les incohérences entre ce qu’ils commercialisent et ce qu’ils mesurent/fournissent constituent un signal d’alarme. Si un fournisseur se vante d’être moderne et piloté par AI, tout en utilisant les mêmes KPI et méthodes d’il y a des décennies, son innovation est probablement superficielle.
Algorithmes et pratiques obsolètes: La théorie de la supply chain a évolué (par exemple, du modèle déterministe aux modèles stochastiques, de l’optimisation à un seul échelon à l’optimisation multi-échelons), mais certains logiciels n’ont pas suivi le rythme. Le recours à des pratiques datant de plusieurs décennies est une faiblesse, surtout si les fournisseurs font semblant du contraire. Par exemple, un outil qui utilise encore principalement la logique de stock de sécurité + point de commande avec des délais fixes pour les stocks est dépassé s’il ne prend pas en compte de manière dynamique la variabilité de la demande. Nous avons remarqué que Slimstock se concentre explicitement sur des formules traditionnelles (stock de sécurité, EOQ) ²¹ – ils sont transparents à ce sujet, ce qui convient pour une solution basique, mais ce n’est clairement pas à la pointe de la technologie. Si un fournisseur censé être avancé n’est pas transparent, il se peut qu’il fasse la même chose sans l’admettre. Un autre exemple : les extraits open-source de Blue Yonder pointaient vers des modèles ARMA ⁴⁷, qui sont des techniques de prévision des séries temporelles des années 1970, même si leur présentation commerciale parle d’AI. Infor, Oracle, John Galt et d’autres fournisseurs de rang inférieur s’appuient de manière similaire souvent sur des méthodes de séries temporelles et des heuristiques qui existent depuis toujours (comme le lissage exponentiel de Winters ou de simples solveurs d’optimisation) – ces méthodes fonctionnent, mais il n’y a rien de moderne à leur sujet. Le signal d’alarme n’est pas d’utiliser d’anciennes méthodes en soi (certaines méthodes anciennes peuvent encore être idéales dans certains cas), c’est les utiliser tout en prétendant être innovants, ou les utiliser exclusivement alors que de meilleures méthodes existent pour le problème. Interrogez toujours sur quels algorithmes sont réellement employés (par exemple : « Votre optimisation de stocks prend-elle en compte l’ensemble de la distribution de la demande ou juste un seul facteur de service ? Utilisez-vous l’optimisation multi-échelons ou seulement des calculs de nœud unique ? »). Des réponses évasives ou vagues indiquent que la méthodologie pourrait être obsolète.
Manque de transparence technique: Enfin, un signal d’alarme méta : si un fournisseur ne fournit aucune documentation technique – ni livres blancs, ni architecture de référence, ni explications des algorithmes – cela constitue en soi un signe d’alerte. Dans nos recherches, les fournisseurs qui ont obtenu de bons scores techniques (Lokad, Kinaxis, SAS, etc.) disposent d’au moins un certain contenu technique (qu’il s’agisse de blogs, d’articles académiques ou de notes techniques). Ceux ayant obtenu de mauvais scores n’ont souvent rien de plus que des brochures marketing. Par exemple, essayez de trouver un livre blanc technique détaillé de o9 ou de Blue Yonder – c’est presque impossible, vous n’obtenez que de jolies brochures. Lokad, en revanche, a publié une étude de marché détaillée de 18 pages (que nous avons citée abondamment) comparant les approches des fournisseurs ⁴⁸ ²⁸ ²⁴, ainsi que des vidéos expliquant le fonctionnement de leurs algorithmes. Lorsqu’un fournisseur reste secret sur la manière dont sa solution fonctionne, il faut se demander si c’est parce qu’elle n’est pas réellement spéciale. La transparence est corrélée à la crédibilité. Un fournisseur se cachant derrière des buzzwords et ne divulguant pas ses méthodes a probablement « une technologie ordinaire avec un supplément de fard ».

En conclusion, appliquer une approche extrêmement sceptique, axée sur l’ingénierie révèle que de nombreux logiciels dits « leaders » d’optimization de la supply chain regorgent de promesses mais manquent d’innovation vérifiable. En éliminant le superflu marketing, nous nous sommes concentrés sur ce qui est tangible : les structures de données, les algorithmes, la performance et la preuve d’efficacité. Les solutions meilleures se distinguaient en offrant une substance technique – une précision démontrée des prévisions, des choix architecturaux clairs et une documentation franche – tandis que les solutions plus faibles se révélaient par des contradictions, des imprécisions et des fondations obsolètes. Cette étude rappelle à tout praticien de la supply chain : ne prenez pas les affirmations des fournisseurs pour argent comptant. Exigez des preuves, regardez sous le capot, et souvenez-vous que dans la supply chain, comme dans l’IT en général, les véritables avancées à la pointe de la technologie sont généralement soutenues par une science ouverte et une ingénierie solide – et non par de hautes promesses marketing.