Logiciel d'optimisation 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 premier plan. Lokad se distingue par sa transparence et sa profondeur technique. Il a été le pionnier de la prévision probabiliste et a prouvé ses méthodes lors d’une compétition ouverte (classé n°1 au niveau SKU et n°6 au classement général sur 909 équipes dans le concours de précision de prévision M5 ¹ - la seule équipe dirigée par un fournisseur dans les premiers rangs). Lokad publie des insights détaillés 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 les décisions financièrement optimisées plutôt que sur des métriques simplistes. Son focus sur les mathématiques rigoureuses (prévisions quantiles, optimisation stochastique) et des flux de travail entièrement scriptables et automatisés (via des APIs et du codage) démontre une conception axée sur l’ingénierie. Aucune grande revendication en matière d’IA/ML n’est faite sans preuve - au lieu de cela, Lokad fournit des articles techniques et même des outils open-source pour mettre à l’échelle les données au-delà des limites de la RAM ² ³. Ce niveau d’ouverture et de performance prouvée place Lokad en tête.
Anaplan - Plateforme “Excel 2.0”. Anaplan est essentiellement la version SaaS d’entreprise d’un tableur, alimentée par son moteur en mémoire Hyperblock propriétaire ⁴. Techniquement, Hyperblock est un moteur de calcul multidimensionnel robuste qui permet à des milliers d’utilisateurs de collaborer sur des modèles de planification en temps réel - similaire à un Excel basé sur le cloud suralimenté. Bien qu’Anaplan ne soit pas un optimiseur de la supply chain spécialisé en soi (la prévision et l’optimisation algorithmique sont des “citoyens de deuxième classe” sur cette plateforme ⁵), 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 personnalisée. En bref, c’est un puissant outil de planification général avec une approche honnête - pas de revendications exagérées sur la magie de la prévision, juste un système de type tableur bien conçu et évolutif. Cette proposition technique directe vaut à Anaplan un haut rang en termes de crédibilité.
Kinaxis (RapidResponse) - Moteur de Simulation en Mémoire. Kinaxis est connu pour son moteur de concurrence unique qui permet de recalculer les plans d’approvisionnement en temps réel dans toute l’entreprise. Techniquement, Kinaxis a construit son propre moteur de base de données à partir de zéro pour prendre en charge cela ⁶ ⁷. Le résultat est une plateforme optimisée pour les simulations rapides de type “et si” : les utilisateurs peuvent créer des scénarios (comme Git pour les données) et obtenir un retour instantané sur l’impact des changements ⁸. Le système garde toutes les données de la supply chain en mémoire pour la rapidité, avec des algorithmes ayant un accès direct à la mémoire pour un débit maximal ⁹. Cette conception permet une planification concurrente réelle (par exemple, les plans de vente, de production et de stocks mis à jour en temps réel ensemble). D’un point de vue technique, la construction d’un magasin de données en mémoire contrôlé par version est un exploit impressionnant qui offre de l’agilité. Le compromis, cependant, est une demande matérielle élevée - une approche entièrement en mémoire signifie que l’extension à des tailles de données massives peut être coûteuse (à mesure que les besoins en RAM augmentent) ¹⁰. Dans l’ensemble, Kinaxis montre une rigueur technique solide en termes d’architecture et de performance, tout en évitant les revendications à la mode sur l’IA. Il excelle dans la planification de l’approvisionnement 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’analyse vétéran (fondée en 1976) et apporte un redoutable moteur de modélisation statistique aux problèmes de la supply chain. Son produit phare comprend un langage spécifique au domaine pour les statistiques (le langage SAS) datant des années 1970 ¹¹ - probablement la plateforme de science des données originale. La force de SAS réside dans la profondeur de ses algorithmes : une vaste bibliothèque de modèles de prévision de séries temporelles, de routines d’optimisation et de techniques d’apprentissage automatique construite sur des décennies. Il emploie certains des ingénieurs et statisticiens les plus talentueux de l’industrie ¹¹, et il a été un pionnier de la prévision avancée bien avant que “IA” ne soit un mot à la mode. Dans les contextes 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é aux langages open-source comme Python/R, et en effet les notebooks Jupyter sont maintenant une alternative ouverte supérieure ¹²). SAS ne revendique pas bruyamment une IA magique; il s’appuie sur sa réputation et sa technologie solide. Pour les organisations ayant l’expertise pour l’exploiter, SAS offre une puissance analytique sérieuse ancrée dans de vrais algorithmes (ARIMA, ETS, etc.) plutôt que du battage médiatique. Son principal inconvénient est qu’il s’agit d’une plateforme d’analyse générale - extrêmement puissante sous le capot, mais nécessite des utilisateurs qualifiés pour l’appliquer à la supply chain, et il n’a pas été spécifiquement évalué dans des compétitions de prévision récentes (des outils open-source le rivalisent souvent ¹³).
Dassault Systèmes (Quintiq) – Spécialiste de l’optimisation. Quintiq (acquis par Dassault Systèmes en 2014) est une plateforme axée sur l’optimisation et la planification de la chaîne d’approvisionnement complexe. Il dispose d’un langage spécifique au domaine appelé Quill pour modéliser les contraintes commerciales ¹⁴. Ce DSL permet aux ingénieurs d’encoder des solutions sur mesure (par exemple, des calendriers de production personnalisés ou des plans de routage) et de tirer parti des solveurs mathématiques. L’existence même d’un DSL dans le produit est une preuve de sérieuse compétence en deep-tech – 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’optimisation du réseau logistique 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 chaîne d’approvisionnement. Cependant, l’accent mis par Quintiq sur l’optimisation se fait au détriment d’autres domaines : par exemple, il a des capacités de prévision natives relativement limitées ¹⁶. Une autre préoccupation est que les mises à jour techniques publiques sur Quill sont rares, laissant 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 des solutions, et sans documentation publique claire, il est difficile d’évaluer les innovations récentes. En résumé, Quintiq est un choix de premier ordre pour les besoins d’optimisation complexes et démontre une forte ingénierie via son DSL – mais il n’est pas aussi transparent ou à jour dans des domaines comme l’IA/la prévision, et ses forces résident dans ce que les implémentateurs construisent avec lui plutôt que dans l’intelligence “prête à l’emploi”.
ToolsGroup (SO99+) – Pionnier probabiliste avec des réserves. Le logiciel de ToolsGroup (SO99+) s’est longtemps spécialisé dans la prévision de la demande et l’optimisation des stocks, en mettant l’accent sur les modèles probabilistes. Il offre une fonctionnalité étendue de chaîne d’approvisionnement (planification de la demande, réapprovisionnement, optimisation des stocks multi-échelons) et était l’un des premiers fournisseurs à vanter des prévisions probabilistes “Puissamment Simples”. Sur le papier, cela semble avancé – ToolsGroup affirme modéliser l’incertitude de la demande et “auto-ajuster” les prévisions, ce qui devrait permettre des cibles de stocks plus précises. Cependant, un examen technique approfondi soulève des préoccupations. Les documents publics de ToolsGroup laissent encore entendre l’utilisation de modèles de prévision d’avant 2000 en interne ¹⁸ – ils ont ajouté un vernis “IA” dans le marketing, mais sans spécificités. De manière révélatrice, depuis 2018, ils annoncent des prévisions probabilistes tout en se vantant simultanément d’améliorations du MAPE ¹⁹. Il s’agit d’une contradiction flagrante : si les prévisions sont vraiment des distributions probabilistes, des métriques comme le MAPE (qui mesure la précision des valeurs uniques) ne s’appliquent plus directement ¹⁹. De telles incohérences suggèrent que la partie “probabiliste” pourrait être superficielle ou qu’ils s’adressent à d’anciennes métriques malgré de nouvelles méthodes. De plus, ToolsGroup a utilisé des mots à la mode comme “IA de détection de la demande”, mais ces affirmations ne sont pas étayées par la littérature scientifique ou par un quelconque benchmark connu ²⁰. En pratique, de nombreuses implémentations de ToolsGroup fonctionnent toujours comme des systèmes automatisés basés sur des règles avec des alertes d’exception. En conclusion : ToolsGroup a une fonctionnalité étendue et était en avance en préconisant la modélisation de l’incertitude, mais son manque de transparence sur les algorithmes et l’écart entre le marketing et la réalité en matière d’IA/ML ne font que modérer sa crédibilité technique. C’est un ensemble d’outils solide et axé sur le domaine, mais pas clairement à la pointe de la technologie selon les normes actuelles.
Slimstock (Slim4) - Simple et Solide. Slimstock est un cas à part rafraîchissant qui ne suit pas les tendances. Son logiciel Slim4 se concentre sur les techniques de la supply chain classiques - des choses comme les calculs de stock de sécurité classiques, les points de commande, la quantité économique de commande (QEO), etc. ²¹. En d’autres termes, Slimstock se conforme à des méthodes bien établies et éprouvées enseignées dans les manuels. Bien que cela signifie pas d’IA/ML sophistiquée ou d’algorithmes de pointe, cela signifie également que Slim4 est fiable et facile à comprendre. Le fournisseur évite explicitement les revendications vagues en matière d’IA et met plutôt l’accent sur des fonctionnalités pratiques qui répondent aux besoins quotidiens de la supply chain ²². Cette honnêteté est un mérite 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 être une limitation - vous n’obtiendrez pas de prévisions de demande probabilistes ou d’optimiseurs avancés de 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 technologique est probablement une base de données standard avec une mise en cache en mémoire, adaptée aux problèmes de taille moyenne). Mais pour de nombreuses entreprises, plus simple est mieux si cela signifie que l’outil fonctionne de manière cohérente. Slimstock gagne des points de crédibilité en évitant le jargon à la mode ; son approche “directe au but” est saluée par ses pairs comme un contraste avec la posture en matière d’IA des autres ²³. En résumé, Slim4 ne repousse pas les limites technologiquement, mais c’est un choix judicieux pour la prévision fondamentale et la gestion des stocks avec un minimum de battage médiatique et une architecture claire et peu risquée.
o9 Solutions - Machine à Hype Haute Technologie. o9 se présente comme un “cerveau numérique” pour la supply chain de l’entreprise, combinant la prévision de la demande, la planification de l’approvisionnement, le S&OP, et même la gestion des revenus sur une 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 le “Graphique de Connaissance d’Entreprise (EKG)”, et divers composants d’IA/ML. La masse technologique pure de o9 est hors normes ²⁴ - selon les normes des logiciels d’entreprise, c’est une architecture très ambitieuse qui tente d’unifier toutes les données et les analyses de planification. Cependant, en appliquant le scepticisme : une grande partie de cela semble être de la technologie pour la technologie, sans bénéfice clair. La conception en mémoire de o9 garantit des coûts matériels extrêmement élevés à grande échelle ²⁵, similaire à l’exécution continue d’un énorme cube BI. o9 vante son EKG (graphique de connaissance) comme permettant des prévisions supérieures et des insights pilotés par l’IA, mais aucune preuve scientifique ou benchmarks crédibles ne sont fournis ²⁵. En fait, bon nombre des affirmations tapageuses de o9 s’effondrent sous examen : l’entreprise parle d’IA partout, pourtant des morceaux de leur code publiquement visible sur GitHub révèlent des techniques plutôt banales ²⁶. Par exemple, o9 a annoncé des fonctionnalités comme la prévision de la demande par apprentissage automatique et des simulations de “jumeaux numériques”, mais elle n’a pas démontré cela dans une compétition publique ou une étude de cas examinée par des pairs. Sans preuve, nous devons considérer ses revendications en matière d’IA comme du marketing tapageur. Cela dit, o9 n’est pas sans forces - c’est une plateforme unifiée (développée en interne, pas une amalgamation d’acquisitions) et peut gérer l’intégration de données à grande échelle. Pour une entreprise prête à investir dans du 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 technique, c’est une solution sur-ingeniérée : beaucoup de complexité, un retour sur investissement peu clair sur la technologie sophistiquée, et des problèmes de performance potentiels si les données dépassent ce que la mémoire peut contenir. Jusqu’à ce que o9 fournisse des preuves tangibles (par exemple, documentation d’algorithme ou résultats de benchmark), sa crédibilité reste douteuse.
SAP IBP (Integrated Business Planning) – Complet mais complexe. La suite IBP de SAP 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 des stocks, planification de l’approvisionnement, planification des ventes et des opérations, et plus encore - le tout étroitement intégré à l’ERP de SAP. La force de SAP IBP réside dans sa largeur : il possède un module pour presque tous les aspects de la planification, souvent avec des fonctionnalités très riches héritées de décennies d’expérience de SAP. Cependant, cette largeur est le fruit 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 des stocks) et d’autres ²⁷ et les a superposés à ses outils internes (comme APO et HANA). Le résultat sous-jacent est un patchwork de moteurs et d’approches différents ²⁷. En conséquence, l’architecture technique d’IBP n’est pas élégante - c’est une collection de composants qui ne se “mélangent” pas naturellement, nécessitant des efforts d’intégration importants. Même la documentation de SAP reconnaît la grande complexité et le besoin de systèmes intégrateurs de haut niveau (et de temps substantiel) pour que tout fonctionne en douceur ²⁸. Sur le plan technologique, IBP s’appuie fortement sur SAP HANA, une base de données colonne en mémoire, pour obtenir des performances en temps réel. HANA est en effet rapide, mais aussi coûteux - stocker de grandes données de planification uniquement en RAM est intrinsèquement coûteux (la RAM est environ 100 fois plus chère par téraoctet que le stockage sur disque) ¹⁰. Cela signifie que mettre à l’échelle IBP pour de très grands ensembles de données de la supply chain entraîne des coûts d’infrastructure importants, et si les données dépassent la mémoire, les performances peuvent chuter brusquement. SAP a commencé à ajouter quelques fonctionnalités d’apprentissage automatique (par exemple, “Demand Driven MRP” et IBP for Demand propose quelques options de prévision ML), mais celles-ci sont principalement des modules complémentaires optionnels avec une transparence limitée. Il n’y a pas de preuve que l’apprentissage automatique de SAP est supérieur aux alternatives ; en fait, aucun algorithme SAP n’a fait ses preuves dans des compétitions de prévisions indépendantes. En résumé, SAP IBP est riche en fonctionnalités et testé en entreprise - il cochera toutes les cases en termes de fonctionnalités - mais d’un point de vue de la pureté technique, c’est un mélange : vitesse en mémoire mariée à la 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 SAP ERP plutôt que pour son excellence en matière d’optimisation.
Blue Yonder - Leader historique devenu patchwork. Blue Yonder (anciennement JDA Software) propose une suite complète couvrant la prévision, la planification de l’approvisionnement, la marchandisation et l’exécution. C’est le résultat de nombreuses années de fusions et acquisitions, notamment l’acquisition par JDA de i2 Technologies (planification de la supply chain), Manugistics et la start-up en IA Blue Yonder (dont elle a adopté le nom) entre autres ²⁹. Malheureusement, les logiciels d’entreprise ne sont pas une simple somme de parties : sous la marque unifiée Blue Yonder se cache un patchwork de produits (dont beaucoup sont assez anciens) assemblés de manière lâche ²⁹. D’un point de vue technique, les solutions de Blue Yonder vont des moteurs de prévision déterministes de l’ancienne école aux modules d’optimisation des stocks qui n’ont pas fondamentalement changé depuis plus de 15 ans. La société met fortement en avant les capacités “IA” et “ML” de sa plateforme Luminate, mais les détails sont rares. En fait, les quelques artefacts publics que nous pouvons trouver - tels que des projets open source et des brevets attribués à l’équipe de data science de Blue Yonder - suggèrent qu’ils utilisent des méthodes assez traditionnelles (par exemple, l’extraction de caractéristiques des séries temporelles, les modèles ARMA et de régression linéaire) ³⁰. Ces techniques sont bonnes, mais ce sont des approches vieilles de plusieurs décennies maintenant souvent surpassées par des méthodes plus récentes. Il semble que l’IA tant vantée de Blue Yonder pourrait simplement être une régression et des heuristiques reconditionnées. Sans études de cas transparentes ou articles techniques, on doit supposer que les affirmations de “prévision IA révolutionnaire” de Blue Yonder sont du pur marketing. De plus, l’intégration de tous ses composants acquis est un défi permanent - de nombreux clients notent des difficultés à tenir la promesse “de bout en bout” car les modules (demande, approvisionnement, exécution, etc.) ne se connectent pas naturellement sans une personnalisation significative. En mémoire ou sur disque ? Blue Yonder ne fait pas la publicité 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 standard. Cela pourrait en fait être un atout en termes de coût, mais cela signifie également que les performances peuvent être en retard à 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 un exemple à suivre : autrefois leader de l’industrie, il propose désormais une suite large mais techniquement incohérente. Ses forces résident dans l’expérience du domaine et un ensemble de fonctionnalités étendu, mais ses faiblesses sont une technologie obsolète sous un nouvel habillage et un manque de preuves crédibles pour ses nouvelles capacités “IA”.

(Note : D’autres fournisseurs comme Infor (avec les composants hérités GT Nexus et Mercia), GAINS Systems (un autre spécialiste de l’optimisation des stocks), John Galt Solutions (planification de la demande pour les moyennes entreprises), Relex Solutions (prévision de la 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 en mémoire, style cube OLAP - idéal pour la vitesse, mais garantit des coûts matériels élevés pour les grands détaillants ³¹ ; Infor a grandi par acquisitions entraînant des problèmes d’intégration similaires à SAP/Blue Yonder ; GAINS et John Galt offrent des fonctionnalités de base solides mais peu documentées publiquement sur des techniques novatrices. Tout fournisseur ne partageant pas ouvertement de détails techniques ou de points de preuve serait de toute façon classé bas dans la méthodologie de cette étude.)*

Analyse technique approfondie

Dans cette section, nous approfondissons des aspects techniques spécifiques des principaux logiciels d’optimisation de la supply chain, en mettant l’accent sur quatre domaines clés : Prévision & IA, Capacités d’automatisation, Architecture du système et Intégration des modules. Toute analyse est ancrée dans des informations techniques publiées ou des preuves concrètes, évitant explicitement tout langage marketing.

Capacités de Prévision & IA

La planification moderne de la supply chain repose sur l’exactitude de la prévision de la demande, pourtant les revendications de supériorité en matière de prévision sont nombreuses et souvent infondées. Notre enquête a révélé que les capacités de prévision de la plupart des fournisseurs ne dépassent pas significativement les méthodes statistiques standard - malgré les mots à la mode tels que “IA” ou “apprentissage automatique” dans leur marketing.

Performance prouvée vs. Hype: Parmi tous les fournisseurs, Lokad est le seul à avoir un bilan de prévision de classe mondiale vérifiable, grâce à la compétition ouverte M5. Lokad a démontré son expertise en matière de prévision probabiliste en se classant en tête pour l’exactitude au niveau du SKU ¹. Cela donne du crédit aux affirmations de Lokad concernant une meilleure précision de la prévision. En revanche, aucun autre fournisseur n’a publié de résultats comparables sur un banc d’essai indépendant. Par exemple, certains fournisseurs font la publicité d’algorithmes propriétaires (l’un appelle sa méthode “Procast”) affirmant une précision supérieure, pourtant ces méthodes étaient absentes des premiers rangs de la compétition M5 ³². En pratique, les approches académiques open-source (comme les packages de prévision R 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 concernant une “meilleure précision de prévision de l’industrie” sans preuve publique devrait être considérée comme non étayée.
Revendications en matière d’IA et d’apprentissage automatique: Nous avons appliqué un scepticisme extrême aux buzz autour de l’IA/ML. Des fournisseurs tels que o9 Solutions et Blue Yonder utilisent abondamment des termes comme “prévision pilotée par l’IA/ML” dans leurs brochures. Cependant, en cherchant des preuves tangibles, nous en avons trouvé peu. Dans le cas de o9, leurs affirmations selon lesquelles le “graphique de connaissances d’entreprise” basé sur les graphes donne de meilleures prévisions sont douteuses sans aucun soutien scientifique ²⁵. Blue Yonder met également en avant l’IA 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 de séries temporelles assez ordinaires (ARMA, régression linéaire, ingénierie des caractéristiques) ³⁰. Il n’y a pas de preuve d’apprentissage profond, de méthodes probabilistes avancées ou d’autres techniques d’IA modernes qui justifieraient leur marketing. ToolsGroup a incorporé des concepts d’apprentissage automatique (ils parlent de “détection de la demande” utilisant l’apprentissage automatique), mais encore une fois aucune étude évaluée par des pairs ou victoires en compétition pour le valider ²⁰. En fait, l’association de ToolsGroup de “prévision probabiliste” avec d’anciennes mesures comme le MAPE suggère que leur IA est plus un buzz qu’une innovation ¹⁹. Conclusion: En dehors de Lokad (et dans une certaine mesure SAS, qui utilise des modèles statistiques éprouvés dans le temps), la prévision dans la plupart des logiciels de supply chain reste basée sur des méthodes connues (lissage exponentiel, régression, peut-être quelques techniques de ML basées sur des arbres) et non sur un génie IA propriétaire. Les fournisseurs qui ont vraiment des algorithmes novateurs les démontreraient publiquement. Le manque de validation indépendante est révélateur.
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 s’en tient à des 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 stock) directement à partir des prévisions probabilistes. ToolsGroup affirme également produire des prévisions probabilistes (probablement via des simulations de Monte Carlo de la demande). Cependant, nous avons constaté que nombreux sont ceux qui revendiquent le terme “probabiliste” mais reviennent toujours à des mesures et processus déterministes en interne. Par exemple, le marketing de ToolsGroup sur la réduction du MAPE en utilisant des modèles probabilistes est incohérent, car le MAPE ne peut même pas être calculé sur une sortie de prévision probabiliste ¹⁹. Cela suggère que leur processus finit par revenir à une prévision ponctuelle (moyenne ou médiane) pour l’évaluation, sapant ainsi l’avantage probabiliste. D’autres fournisseurs comme SAP, Oracle, Blue Yonder ont commencé à mentionner des termes probabilistes (SAP IBP a maintenant des “ensembles statistiques” et des intervalles de confiance), mais encore une fois, leurs interfaces utilisateur et leurs rapports se basent souvent sur 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 KPI (en utilisant la perte de Pinball, le CRPS ou l’atteinte du taux de service au lieu du MAPE). Nous n’avons trouvé aucune preuve qu’aucun grand fournisseur, sauf Lokad, soit allé aussi loin dans la 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 certaines distributions en coulisses, mais les planificateurs regardent toujours des chiffres de prévision ponctuelle et des 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é des prévisions. Un signal d’alarme est la dépendance continue à des métriques comme le MAPE, le WAPE ou le biais comme seules mesures de succès, surtout si le fournisseur prétend utiliser l’IA ou des méthodes probabilistes. Cela est dû au fait que ces métriques encouragent des prévisions conservatrices et moyennes et peuvent être manipulées (par exemple, en éliminant les extrêmes). Nous avons observé que les fournisseurs avec des prévisions vraiment avancées tendent à parler de taux de service ou de résultats commerciaux (par exemple, probabilité de rupture de stock, impact sur les coûts) au lieu de simplement du MAPE. Lokad, par exemple, met l’accent sur la réduction des “dollars d’erreur” et l’alignement des prévisions avec l’optimisation des décisions ³³. En revanche, ToolsGroup, Blue Yonder et beaucoup d’autres mettent toujours en avant les erreurs en pourcentage dans leurs études de cas, montrant une mentalité dépassée. Si la documentation ou la démonstration d’un fournisseur met fortement en avant des tableaux de bord MAPE/WAPE, c’est un signe que leurs prévisions sont probablement traditionnelles. En effet, l’incohérence de ToolsGroup sur le MAPE a déjà été notée ¹⁹. En bref : des prévisions vraiment à la pointe dans la supply chain seraient attestées par des métriques probabilistes et une validation dans le monde réel - attributs principalement absents en dehors d’un ou deux acteurs.

Capacités d’Automatisation et de Workflow

Réaliser l’optimisation de la supply chain ne se résume pas seulement aux algorithmes ; il s’agit également de la manière dont le logiciel peut exécuter le processus de planification de manière automatisée et “sans intervention”. Nous avons examiné les revendications et la documentation de chaque fournisseur pour trouver des preuves de l’automatisation, de l’intégration API et du support à la prise de décision autonome.

Lokad : L’automatisation est l’une des marques de fabrique de Lokad. La solution entière est construite autour d’un langage spécifique au domaine (Envision) qui permet aux planificateurs de la supply chain d’encoder leur logique et leurs décisions dans des scripts, qui s’exécutent ensuite automatiquement selon un calendrier. Lokad documente clairement ses pipelines de données et son gestionnaire de workflow qui rafraîchit les données et re-calcule les décisions (prévisions, commandes de réapprovisionnement, etc.) sans intervention manuelle ³⁴ ³⁵. Ils discutent même de la mise en place de “configurations hautement automatisées” pour environ 100 supply chains en production ³⁵, ce qui signifie que le logiciel extrait les données, fait des prévisions et produit des décisions (comme des propositions de bons de commande) de manière automatisée. De plus, Lokad fournit des APIs pour le téléchargement des données et des résultats, et a un concept de “Pilote IA” pour automatiser les tâches administratives ³⁶. Tout cela indique un très haut niveau d’automatisation réelle - le rôle de l’utilisateur est principalement de surveiller et de peaufiner le code/les paramètres, et non de pousser manuellement 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 à automatisées ³⁷ ³⁸).
Kinaxis : Kinaxis RapidResponse est conçu pour l’analyse rapide de scénarios et la collaboration plutôt que pour une planification entièrement automatisée. Le concept de “planification simultanée” consiste à ce que tout le monde travaille sur le même jeu de données avec des mises à jour en temps réel, mais cela implique généralement encore des planificateurs humains pour évaluer les scénarios et prendre des décisions. Cela dit, Kinaxis prend en charge l’automatisation de certaines manières : il peut ingérer des données des systèmes ERP en quasi temps réel, exécuter ses algorithmes d’adéquation offre/demande en continu, et déclencher des alertes ou des messages d’exception aux utilisateurs lorsque les choses sortent des limites. Il expose des fonctionnalités via des APIs et propose des scripts (sous forme d’algorithmes configurables et de macros dans son environnement) pour les utilisateurs avancés. Cependant, Kinaxis se positionne généralement comme un support à la décision, et non comme une boîte noire qui libère automatiquement des commandes. Le fournisseur ne revendique pas haut et fort une “supply chain autonome”; il se concentre plutôt sur la rendu des planificateurs plus efficaces. C’est une position honnête. Cela signifie que de base, RapidResponse s’attend toujours à avoir des humains dans la boucle - ce qui peut être 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 les plans approuvés), mais une opération de bout en bout sans surveillance nécessiterait beaucoup de configurations personnalisées. Nous n’avons pas trouvé de preuves montrant que Kinaxis fournit des recommandations de décisions basées sur l’IA (leur force réside davantage dans le calcul rapide de scénarios définis par les utilisateurs).
o9 Solutions : o9 met fortement en avant des concepts tels qu’un “jumeau numérique” de l’organisation et une IA capable de faire des recommandations. Ils parlent d’“Automatisation” dans le contexte de leurs assistants numériques - vraisemblablement des bots capables de mettre en lumière des informations ou d’accomplir certaines tâches. Cependant, en l’absence de documentation technique concrète, il est difficile de déterminer ce qui est réel. Nous n’avons pas trouvé de détails tels que “o9 peut automatiquement libérer des commandes de réapprovisionnement via une API basée sur ses plans” ou “o9 utilise l’apprentissage par renforcement pour ajuster ses paramètres de manière autonome.” La vaguité du récit d’automatisation de o9 est préoccupante : beaucoup de discours de haut niveau, peu de détails. Étant donné sa base EKG en mémoire, nous soupçonnons que o9 est capable de mises à jour et de recalculs de données en temps réel, mais qu’il dépend probablement encore des utilisateurs pour configurer ce qu’il convient de faire avec ces informations. Sans références crédibles, nous considérons les affirmations d’“autonomie” de o9 comme non vérifiées. Il est possible d’intégrer o9 via des APIs dans des systèmes d’exécution (c’est un logiciel moderne, donc l’intégration API devrait exister), mais il n’est pas clair dans quelle mesure la prise de décision est réellement automatisée par l’IA dans o9. Les preuves suggèrent que l’automatisation actuelle de o9 est davantage axée sur l’accélération des analyses (par exemple, des scénarios de simulation instantanés) que sur l’automatisation des sorties de décision.
Blue Yonder : Ces dernières années, Blue Yonder (surtout depuis son acquisition par Panasonic) a mis en avant le terme “supply chain autonome”, impliquant un système capable de fonctionner avec une intervention humaine minimale. Ils ont certains composants, comme Luminate Control Tower, qui utilisent l’IA pour détecter les perturbations et déclencher éventuellement des réponses. Cependant, étant donné le cœur hérité de Blue Yonder, il est probable que toute autonomie soit obtenue en superposant des RPA (Automatisation des Processus Robotiques) ou des agents d’IA simples sur des modules existants. Par exemple, la planification de la demande de Blue Yonder pourrait produire une prévision, et une couche “IA” pourrait l’ajuster automatiquement en fonction des 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 l’émission automatique de commandes, l’ajustement automatique des politiques d’inventaire) est probablement rare avec les solutions de BY - les clients ont généralement encore des planificateurs pour vérifier et approuver les actions. 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 avaient un planificateur vraiment autonome, ils publieraient des études de cas ou des blogs techniques à ce sujet. Au lieu de cela, ils publient principalement des webinaires marketing. Ainsi, nous déduisons que Blue Yonder permet une certaine automatisation (comme des travaux par lots, des mises à jour de plans, peut-être une intégration en boucle fermée avec des systèmes d’exécution), mais il n’est pas démontrablement en avance dans ce domaine. Il utilise probablement une planification basée sur les exceptions similaire aux anciens systèmes (juste avec un nouvel aspect d’IA sur le système d’alerte).
ToolsGroup: ToolsGroup s’est historiquement vanté de son “Automatisation Puissamment Simple”. Ils affirmaient que leur système pouvait fonctionner en mode lights-out pendant de longues périodes, ne faisant intervenir les planificateurs que pour les exceptions. En effet, la philosophie de ToolsGroup était de laisser le système revoir et replanifier automatiquement chaque jour, en s’adaptant aux nouvelles données. À leur crédit, de nombreux clients de ToolsGroup ont signalé une réduction de la charge de travail des planificateurs car le logiciel ajuste automatiquement les cibles de stock et recommande les commandes automatiquement. ToolsGroup dispose également d’une trousse d’intégration pour alimenter les commandes approuvées dans les systèmes ERP. Cependant, en raison des contradictions mentionnées précédemment, nous avons des doutes sur l’intelligence de cette automatisation. Il se pourrait simplement qu’il applique la même formule chaque jour et signale quand quelque chose ne va pas (gestion des exceptions). ToolsGroup fournit une API et prend en charge les exécutions planifiées, donc techniquement l’infrastructure pour l’automatisation est en place. La question est la qualité des décisions automatisées. Ils mentionnent beaucoup l’auto-ajustement - ce qui implique que le logiciel ajuste les paramètres du modèle de prévision de manière autonome à mesure que de nouvelles données arrivent ³⁹. Si c’est vrai, c’est une automatisation utile (éliminant le besoin d’une reconfiguration humaine constante). Sans évaluation indépendante, nous disons avec prudence que ToolsGroup offre une forte automatisation dans les tâches de planification courantes, 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 suit-elle simplement des règles prédéfinies?).
Autres Fournisseurs: La plupart des autres acteurs soutiennent des capacités d’automatisation standard : intégration de données via des API ou des lots de fichiers, exécutions planifiées et certains flux de travail basés sur les exceptions. Par exemple, SAP IBP peut être configuré pour exécuter automatiquement une tâche de prévision chaque mois et remplir les résultats de planification, mais généralement un planificateur examine la sortie. 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 pousser/tirer des données et peut-être automatiser certains calculs. Dassault/Quintiq peut être programmé pour exécuter des routines d’optimisation selon un calendrier (et le DSL de Quintiq signifie que vous pouvez programmer des comportements automatiques personnalisés), mais encore une fois, il est aussi autonome que le programmeur le programme. GAINS, Relex, Netstock et d’autres fournisseurs de niche annoncent tous une “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 de magasin. La différence clé réside dans la quantité de supervision nécessaire : un système de planification vraiment autonome ne ferait appel aux humains que pour des situations inhabituelles et documenterait ses décisions avec des raisonnements. Nous n’avons trouvé aucun fournisseur qui atteigne pleinement cet idéal pour l’instant. Ils nécessitent soit que les humains ajustent et approuvent (dans la plupart des cas), soit ils automatisent seulement les décisions les plus simples et laissent le reste.

Résumé pour l’Automatisation: Seuls quelques fournisseurs (notamment Lokad) détaillent publiquement un cadre d’automatisation permettant des cycles de planification pilotés par API sans surveillance. D’autres ont les moyens techniques pour l’automatisation mais dépendent toujours des humains pour boucler la boucle. Nous notons également que certains fournisseurs ont changé de cap au cours des dernières décennies, passant de l’automatisation complète à 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 être une béquille pour un logiciel qui n’est pas assez robuste pour être pleinement 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” est probablement juste un discours marketing.

Architecture du Système & Scalabilité

L’architecture sous-jacente - en particulier l’utilisation de la mémoire vive par rapport au disque, et les choix de conception globaux - a des implications énormes pour la scalabilité, le coût et les performances d’un logiciel de supply chain. Nous avons examiné la pile technologique de base de chaque fournisseur en mettant l’accent sur la manière dont ils gèrent les grandes données et les calculs complexes.

Calcul en Mémoire Vive – Avantages et Inconvénients : Plusieurs des principaux fournisseurs s’appuient sur une architecture en mémoire vive, ce qui signifie que le logiciel charge la plupart ou toutes les données pertinentes dans la RAM pour un accès rapide lors des calculs. Cela inclut Kinaxis, Anaplan, o9, SAP HANA (IBP), Relex, et éventuellement Quintiq (pour la résolution de scénarios). L’avantage est la vitesse : l’accès à la RAM est des ordres de grandeur plus rapide que le disque. Par exemple, le moteur de Kinaxis place toutes les données en mémoire pour permettre le recalcul instantané des scénarios et les opérations algorithmiques directes sur l’ensemble de données ⁹. HANA de SAP a été construit sur le principe que l’analyse des données en direct devrait se faire en mémoire pour des résultats en temps réel ⁴⁰ ⁴¹. Cependant, il y a un problème fondamental avec une conception entièrement en 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 taille de la mémoire sur les serveurs est physiquement limitée (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 chaînes d’approvisionnement). Ces dernières années, les baisses drastiques attendues du coût de la RAM ne se sont pas concrétisées - les prix et capacités de la RAM sont restés assez stables ⁴². Cela signifie que tout système qui exige que toutes les données soient en mémoire sera confronté à des coûts d’infrastructure en forte hausse à mesure que les données augmentent, ou atteindra un plafond où il ne pourra tout simplement pas stocker les données. Nous qualifions une forte dépendance à la conception en mémoire vive comme une erreur architecturale pour les grandes chaînes d’approvisionnement, sauf si elle est atténuée.
Mémoire vs Disque : Pratiques Modernes : De manière intéressante, le monde de la technologie a réalisé que les solutions purement en mémoire ne sont pas l’avenir du big data. Les nouvelles architectures utilisent une approche hiérarchisée - garder les données chaudes en mémoire et les données froides sur des SSD, etc. ⁴³ ⁴⁴. Certains logiciels de la supply chain ont commencé à adopter cette approche. Par exemple, Lokad utilise explicitement des techniques de “spill to disk” dans son infrastructure cloud. Leur CTO a décrit comment ils gèrent un jeu de données de vente de détail de 10 milliards de lignes en utilisant environ 37 Go de RAM plus un SSD NVMe rapide pour déverser le surplus ⁴⁵ ³. Ils atteignent des performances proches de la RAM en mappant les fichiers en mémoire et en ne gardant que les données les plus chaudes en RAM, le logiciel effectuant des échanges intelligents au besoin ⁴⁶ ⁴⁷. Cette approche permet d’importantes économies de coûts - par exemple, pour le coût de 18 Go de RAM haut de gamme, on peut acheter 1 To de SSD NVMe ³, ce qui revient à 50 fois moins cher par octet tout en étant seulement ~6 fois plus lent en accès brut, un compromis souvent intéressant. Aucun des fournisseurs centrés sur la mémoire (Kinaxis, SAP, o9, etc.) n’a décrit publiquement une telle gestion adaptative de la mémoire, suggérant que leurs solutions pourraient simplement exiger beaucoup de RAM ou nécessiter une agrégation des données pour s’adapter. Anaplan est connu pour rencontrer des limites de taille de modèle - certains clients se heurtent aux limites de mémoire de son Hyperblock et doivent diviser les modèles. Kinaxis a probablement également besoin de plusieurs serveurs connectés en réseau pour des données très volumineuses (ils ont un concept de distribution des données, mais à l’intérieur de chaque nœud, elles sont résidentes en mémoire). SAP HANA peut décharger sur disque (il a des nœuds d’extension), mais les performances en souffrent. En fin de compte : une conception rigide en mémoire est un signal d’alarme pour la scalabilité. Cela peut fonctionner brillamment pour des données de petite à moyenne taille, mais à mesure que la supply chain se développe (pensez : planification détaillée au niveau SKU-magasin-jour pour un détaillant mondial), les coûts et les risques de performances augmentent. L’ingénierie moderne favorise un mélange d’utilisation de la mémoire et du disque pour équilibrer la vitesse et le coût, et les fournisseurs qui ne le font pas sont en retard.
Empile Technologique et Complexité : Au-delà de la mémoire, un autre élément architectural est l’empile technologique globale - monolithique vs microservices, utilisation de langages de programmation modernes, etc. Sans entrer dans les détails, nous avons observé que les anciens fournisseurs (SAP APO/IBP, Blue Yonder) fonctionnent sur des piles plus monolithiques et héritées, tandis que les plus récents (o9, Anaplan) ont construit leur propre solution à partir de zéro avec des technologies plus récentes. Par exemple, le cœur de SAP IBP inclut toujours des moteurs des années 2000 (comme l’optimiseur d’APO) maintenant enveloppés dans une couche HANA/cloud. Cela introduit de la complexité et une inefficacité potentielle (multiples couches d’abstraction). Blue Yonder a également beaucoup de code hérité des jours d’i2 et JDA. Kinaxis est quelque peu unique - il est ancien (créé dans les années 90) mais ils ont continuellement refactorisé dans leur propre noyau de base de données ; c’est toujours une pile propriétaire qu’ils 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 très optimisé pour ce but - mais il n’est pas ouvert, et vous devez vivre avec ses contraintes (par exemple, pas de requêtes SQL, complexité algorithmique limitée puisqu’il repose davantage sur des calculs basés sur les cellules). La plateforme d’o9 inclut un mélange de technologies (probablement une base de données NoSQL/graph, peut-être Spark ou similaire pour certains ML, etc.), ce qui la rend complexe mais théoriquement flexible.
Matériel et Cloud : Une tendance notable est la conception native du cloud. De nombreux fournisseurs proposent désormais leur logiciel en tant que SaaS ou du moins hébergé dans le cloud, mais tous ne sont pas vraiment natifs du cloud. 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 s’exécute sur Microsoft Azure et alloue dynamiquement des ressources). SAP IBP est hébergé dans le cloud mais essentiellement chaque client est une instance isolée sur HANA (pas multi-locataire au même sens). 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 importe-t-il techniquement ? Les architectures natives du cloud sont généralement plus élastiques - elles peuvent allouer des ressources de calcul lorsque nécessaire (pour une grande exécution de planification) et les libérer ensuite, contrôlant ainsi les coûts. Les systèmes non cloud nécessitent souvent l’achat de capacité maximale même s’ils sont utilisés occasionnellement. De plus, les systèmes natifs du cloud peuvent mieux s’intégrer à d’autres services cloud (par exemple, se connecter à un service cloud ML ou un data lake). D’après ce que nous avons trouvé, les solutions les plus nativement cloud et évolutives par conception semblent être Lokad et o9 (et peut-être Anaplan), tandis que d’autres rattrapent leur retard. Cependant, le natif du cloud seul ne signifie pas une bonne architecture - o9 est natif du cloud mais nous avons remis en question son approche lourde en mémoire ; SAP IBP étant dans le cloud ne résout pas ses problèmes de complexité.
Concurrence et Besoins en Temps Réel : Une considération architecturale est la façon dont le système gère les utilisateurs concurrents et les mises à jour en temps réel. Kinaxis brille ici : il a été conçu pour permettre à plusieurs planificateurs de faire de la planification de scénarios simultanément sur le même ensemble de données. Cela nécessite une logique de versionnement et de verrouillage des données soigneuse - que Kinaxis a réalisée via son mécanisme de branchement ⁸. La plupart des autres outils suivaient traditionnellement un paradigme par lots (planifier, publier, puis collaborer séparément). Maintenant, beaucoup ajoutent des fonctionnalités de planification concurrente. 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 “Microsoft Excel-like” qui peut rafraîchir les données du serveur à la demande, mais la vraie concurrence (plusieurs utilisateurs éditant le même plan simultanément) est limitée. o9 prend probablement en charge un certain niveau de concurrence étant donné son graphe de connaissances (plusieurs utilisateurs peuvent ajuster différents nœuds). En évaluant le mérite technique, un système qui peut réellement fonctionner en temps réel avec de nombreux utilisateurs indique une architecture robuste. Kinaxis et Anaplan marquent des points ici. Ce n’est pas que les autres ne peuvent pas le faire, mais souvent leurs anciennes architectures rendent les choses difficiles - entraînant soit des performances lentes, soit des processus séquentiels forcés.

Résumé pour l’Architecture : Nous avons identifié un modèle : les conceptions centrées sur la mémoire (Kinaxis, Anaplan, o9, Relex, SAP HANA) offrent de la vitesse mais au détriment de la scalabilité et des coûts, tandis que les conceptions hybrides (comme 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 clair est tout fournisseur insistant sur le fait que tout doit être en RAM pour fonctionner - cette approche est désormais considérée comme obsolète compte tenu des avancées en matière de vitesse des SSD et de l’informatique distribuée ⁴³ ⁴⁴. Nous soulignons également que les architectures des fournisseurs issues de multiples acquisitions (comme SAP, Blue Yonder) ont tendance à être trop complexes et nécessitent beaucoup de réglages. Les architectures plus simples et internes (codebase unique de Kinaxis, moteur unique d’Anaplan, moteur unique de Lokad) ont tendance à être plus cohérentes et donc plus faciles à maintenir sur le plan technique. En évaluant un logiciel de supply chain, on devrait se demander : Le fournisseur a-t-il publié quelque chose sur la façon dont leur 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 est juste une boîte noire - indiquant souvent soit un héritage, soit un manque de confiance dans leur caractère unique.

Intégration & Cohérence des Modules (Impact des Fusions et Acquisitions)

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

Blue Yonder (JDA) est l’exemple type de croissance par acquisition. Comme mentionné, il s’agit d’une “collection désordonnée” de produits de différentes époques ²⁹. JDA a acquis i2 (qui avait lui-même plusieurs modules), a acquis Manugistics auparavant, puis RedPrairie (pour la gestion d’entrepôt), puis la startup Blue Yonder pour l’IA. Chaque élément avait son propre schéma de base de données, sa propre logique. Le résultat : même aujourd’hui, la planification de la demande, la planification de l’approvisionnement et l’optimisation des stocks de 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’alerte car cela signifie que la mise en œuvre de l’ensemble complet revient essentiellement à intégrer plusieurs logiciels distincts. Lorsque les produits d’un fournisseur ne sont pas vraiment unifiés, les clients rencontrent des problèmes tels que des retards 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 les acquisitions, vous pourriez avoir deux façons de planifier les stocks - une de l’héritage de Manugistics et une de i2). La société a fait des efforts pour rationaliser cela, mais ce n’est pas entièrement résolu. En termes techniques, les logiciels d’entreprise ne se “mélangent” pas magiquement comme des fluides lorsque les entreprises fusionnent ²⁹ - cela prend des années de réingénierie. Nous n’avons pas vu de preuves que Blue Yonder ait achevé cette réingénierie. Ainsi, le manque de cohérence est une faiblesse technique majeure.
SAP IBP a également 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 dans l’ombrelle IBP ²⁷. Les utilisateurs ont noté que IBP dispose de différents modules qui semblent être des applications distinctes (par exemple, IBP pour la Demande vs IBP pour les Stocks). La logique d’optimisation des stocks de sécurité dans IBP provient 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 tout mis sur la base de données HANA), mais sous le capot, IBP n’est pas un seul code source. SAP avertit explicitement que la mise en œuvre de 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 déclaration est en soi un signal d’alerte - elle implique un potentiel de désalignement et de complexité.
Infor (bien qu’il ne soit 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 plateforme de planification vraiment unifiée ; Infor a tendance à se concentrer sur les systèmes d’exécution. C’est donc un autre exemple où l’acquisition n’a pas donné un excellent produit de planification intégré.
Dassault (Quintiq) : Dans ce cas, l’acquisition (par Dassault) n’a pas impliqué la fusion de 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/ordonnancement. Ainsi, la cohérence interne de Quintiq est bonne (elle a été développée en interne et le reste), mais l’inconvénient est qu’elle ne couvre pas tous les domaines (par exemple, pas de prévision de la demande native, comme indiqué ¹⁶). Le portefeuille de Dassault comprend d’autres produits (comme Apriso pour MES, etc.), mais ils ne sont pas intégrés de manière profonde avec Quintiq. Donc, en termes d’intégration, Quintiq est cohérent en interne 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 signifie un travail supplémentaire du côté du client.
Kinaxis a principalement grandi de manière organique - il a acquis une petite entreprise d’IA, Rubikloud, en 2020 (pour l’IA dans le commerce de détail) et un outil de conception de la 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 gérant divers aspects de la planification par configuration. Cette cohérence est un avantage : tous les modules (demande, approvisionnement, stocks) partagent une base de données et une interface utilisateur chez Kinaxis. De même, Anaplan a développé différents “apps” de planification sur une seule plateforme - les plans de vente, de finance, de la supply chain résident tous dans le même environnement Hyperblock, ce qui est techniquement très cohérent (juste des modèles de données 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 les principaux). Ainsi, ces trois - Kinaxis, Anaplan, o9 - ont un avantage architectural d’unité. La prudence avec eux ne concerne pas l’intégration de modules disparates, mais plutôt si leur plateforme unique peut vraiment gérer la profondeur dans chaque domaine.
ToolsGroup & Slimstock : Ces fournisseurs sont restés concentrés sur leur créneau (planification de la demande et des stocks). Ils n’ont pas vraiment acquis d’autres entreprises ; au lieu de cela, ils s’associent ou s’intègrent avec des systèmes d’exécution selon les besoins. Cela signifie que leur logiciel est interne cohérent (un seul code source), ce qui est bon, 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. ToolsGroup a commencé à ajouter des fonctionnalités S&OP ces dernières années et a même acquis une startup d’IA (Eramos en 2018) pour l’apprentissage automatique, mais encore une fois, ceux-ci ont été intégrés dans le produit de base plutôt que vendus séparément. Ainsi, l’intégration n’est pas un gros problème pour ToolsGroup ou Slimstock - le compromis est de savoir si leur conception axée sur un seul objectif couvre suffisamment de domaines pour les besoins de l’utilisateur.

Résumé pour l’Intégration : D’un point de vue sceptique, de multiples acquisitions majeures dans l’histoire d’un fournisseur sont un signe d’alerte. Cela conduit souvent à un produit touche-à-tout qui n’est maître en rien, avec une complexité cachée. Blue Yonder et SAP en sont des exemples - leur complexité technique découle en partie de la tentative de coller ensemble de nombreux éléments hérités. En revanche, les fournisseurs disposant d’une plateforme unifiée unique (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 demander l’origine de chaque module : Si le module de planification de la demande et le module de planification des approvisionnements proviennent de différentes entreprises d’origine, enquêtez sur la manière dont ils partagent les données et si l’intégration est transparente ou via une interface. L’histoire a montré que sauf si la technologie acquise a été réécrite à partir de zéro dans une architecture unifiée (ce qui est rare en raison du coût et du temps), le résultat est généralement un système Frankenstein. Notre recherche confirme cela - les fournisseurs obtenant les meilleures notes en termes d’élégance technique (Lokad, Kinaxis, Anaplan) ont construit leurs solutions de manière holistique, tandis que ceux obtenant les plus faibles notes (Blue Yonder, Infor) ont accumulé des technologies disparates sans les unifier pleinement.

Faiblesses Critiques & Signaux d’Alerte

Dans notre examen rigoureux, nous avons identifié plusieurs faiblesses récurrentes et signaux d’alerte que les utilisateurs potentiels doivent connaître. Voici un résumé des principaux problèmes, avec des exemples de fournisseurs spécifiques pour illustrer chaque point :

Affirmations “IA/ML” non fondées : Soyez extrêmement sceptique envers tout fournisseur proclamant une IA ou un apprentissage automatique supérieur sans preuves techniques solides. Par exemple, Blue Yonder fait beaucoup de publicité sur l’IA mais ne fournit que des affirmations vagues sans substance ³⁰ - ce que nous pouvons voir de leurs méthodes indique qu’ils se reposent sur des techniques plus anciennes, et non sur de l’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 “beaucoup de battage médiatique autour de l’IA” avec seulement des analyses pédestres en réalité ²⁶. Si un fournisseur ne peut pas pointer vers des études évaluées par des pairs, des brevets, des compétitions ou des articles techniques détaillés pour étayer ses affirmations en matière d’IA, considérez que c’est du fluff marketing. Les fournisseurs réellement avancés seront fiers de détailler leurs algorithmes.
Pas de comparaison concurrentielle (Affirmations de supériorité en matière de prévision) : De nombreux fournisseurs revendiquent une « précision de prévision de classe mondiale » mais aucun, à part Lokad, ne l’a prouvé dans des compétitions ou des publications ouvertes. Nous considérons toute affirmation de ce type comme fausse à 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 premières places 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 les 100 premiers de ce concours mondial de prévision. C’est un signal d’alarme majeur : cela implique que ces fournisseurs n’ont soit pas participé (peut-être pour éviter l’embarras public), soit ont participé et ont mal performé. Conseil pratique : Exigez de voir des résultats objectifs de précision (par exemple, comment leur outil s’est-il comporté sur un benchmark standard comme l’ensemble de données M5 ou M4) - s’ils ne peuvent pas en fournir, ne tombez pas dans le piège du battage médiatique.
Dépassement de l’architecture en mémoire : Les fournisseurs poussant un design entièrement en mémoire devraient être questionnés sur la scalabilité et le coût. Le calcul en mémoire offre de la vitesse, mais la RAM est ~100 fois plus chère par Go que le disque ¹⁰ et son rapport prix/performance stagne ces dernières années ⁴². Cela rend les solutions purement en mémoire non scalables et coûteuses pour de gros volumes de données. SAP IBP (HANA) et o9 en sont des exemples : ils garantissent des performances élevées uniquement si vous chargez de gros ensembles 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 souligne un expert, l’engouement initial pour tout mettre en RAM a atteint des limites pratiques, et les bases de données « retrouvent leur amour pour le disque » pour gérer efficacement les données froides ⁴³ ⁴⁴. Si un fournisseur est toujours bloqué dans une mentalité uniquement en mémoire, considérez-le comme un signal d’alarme architectural. Les fournisseurs plus scalables parleront de stockage en couches, d’élasticité cloud, ou de stratégies similaires pour gérer des données à grande échelle sans nécessiter de RAM infinie.
Boîte noire issue des fusions-acquisitions (Dysfonctionnement de l’intégration) : Si la suite de produits d’un fournisseur est le résultat de nombreuses acquisitions, méfiez-vous des écarts d’intégration et des fonctionnalités redondantes. Comme nous l’avons vu, la suite de Blue Yonder est un mélange disparate de produits obsolètes en raison d’une longue série de fusions ²⁹, et les modules de SAP IBP proviennent de différentes sociétés acquises ²⁷, ce qui entraîne une complexité et une “collection” d’outils plutôt qu’un ensemble homogène. Les logiciels d’entreprise ne sont pas facilement “miscibles” par le biais des fusions-acquisitions ²⁹ - à moins que le fournisseur n’ait effectué une refonte complète (ce qui est rare et chronophage), le client se retrouve souvent à agir en tant qu’intégrateur entre les modules. Cela peut se traduire par des expériences utilisateur incohérentes, une saisie de données en double et des interfaces fragiles. Symptôme d’alerte : La mise en œuvre du fournisseur nécessite un bataillon de consultants pendant un an ou plus pour faire dialoguer les modules entre eux - comme cela a été reconnu même dans le cas de SAP ²⁸. Privilégiez les fournisseurs disposant d’une plateforme unifiée ou d’un chevauchement minimal dans les composants acquis.
Métriques contradictoires et mots à la mode : Un signe subtil mais révélateur est lorsque l’argumentaire technique d’un fournisseur contient des contradictions internes ou des pratiques obsolètes déguisées sous de nouveaux termes. Un exemple flagrant était ToolsGroup qui faisait la publicité de prévisions probabilistes tout en faisant référence simultanément à des améliorations du MAPE ¹⁹ - un signe qu’ils ne font que saupoudrer de nouveaux termes sur de vieilles pratiques (car utiliser le MAPE pour juger des prévisions probabilistes est conceptuellement incorrect). Un autre exemple est celui des fournisseurs affirmant utiliser une “IA avancée” mais mesurant le succès avec d’anciennes métriques comme le MAPE ou les niveaux de service traditionnels - cela indique qu’ils n’ont pas vraiment adopté le nouveau paradigme. De même, soyez attentif aux méthodologies de stock de sécurité : un fournisseur peut prétendre optimiser les stocks avec l’IA, mais si vous creusez et découvrez qu’ils calculent toujours le stock de sécurité selon une formule des années 1980 (par exemple, 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ù les fournisseurs parlent de stocks “probabilistes” ou “optimaux”, mais leurs documents révèlent des calculs de stock de sécurité standard et l’utilisation de métriques obsolètes comme le taux de remplissage. Conclusion : Les incohérences entre ce qu’ils commercialisent et ce qu’ils mesurent/livrent sont un signe d’alerte. Si un fournisseur se vante d’être moderne et axé sur l’IA, mais utilise les mêmes KPI et méthodes datant de plusieurs décennies, leur innovation est probablement superficielle.
Algorithmes et pratiques obsolètes : La théorie de la supply chain a progressé (par exemple, des modèles déterministes aux modèles stochastiques, de l’optimisation à un seul échelon à l’optimisation à plusieurs échelons), mais certains logiciels n’ont pas suivi. Le recours à des pratiques vieilles de plusieurs décennies est une faiblesse, surtout si les fournisseurs prétendent le contraire. Par exemple, un outil qui utilise principalement la logique du stock de sécurité + point de commande avec des délais fixes pour les stocks est dépassé s’il ne tient pas compte de la variabilité de la demande de manière dynamique. Nous avons remarqué que Slimstock se concentre explicitement sur des formules traditionnelles (stock de sécurité, EOQ) ²¹ - ils sont transparents à ce sujet, ce qui est acceptable pour une solution de base, mais ce n’est clairement pas à la pointe de la technologie. Si un fournisseur soi-disant avancé n’est pas transparent, il pourrait faire 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 de l’ère des années 1970, même si leur argumentaire de vente parle d’IA. Infor, Oracle, John Galt et d’autres dans le bas de gamme se reposent souvent sur des méthodes de séries temporelles et des heuristiques qui existent depuis toujours (comme le lissage exponentiel de Winters, des solveurs d’optimisation simples) - ils 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 (les anciennes méthodes peuvent toujours être les meilleures dans certains cas), c’est de les utiliser en prétendant être innovant, ou de les utiliser exclusivement alors que de meilleures méthodes existent pour le problème. Toujours demander quels algorithmes sont réellement utilisés (par exemple, “Votre optimisation des stocks prend-elle en compte l’ensemble de la distribution de la demande ou seulement un seul facteur de service ? Utilisez-vous l’optimisation à plusieurs échelons ou simplement des calculs à un seul nœud ?”). Des réponses évasives ou vagues indiquent que la méthodologie pourrait être dépassée.
Manque de transparence technique : Enfin, un méta signal d’alarme : si un fournisseur ne fournit aucune documentation technique - aucun livre blanc, aucune architecture de référence, aucune explication des algorithmes - c’est en soi un signe d’avertissement. Dans nos recherches, les fournisseurs qui ont bien performé sur le plan technique (Lokad, Kinaxis, SAS, etc.) ont tous au moins un certain contenu technique disponible (qu’il s’agisse de blogs, d’articles académiques ou de notes techniques). Les fournisseurs qui ont mal performé ont souvent rien de plus que des brochures marketing. Par exemple, essayez de trouver un livre blanc technique détaillé de o9 ou Blue Yonder - c’est presque impossible, vous obtenez surtout des brochures brillantes. Lokad, en revanche, a publié une étude de marché détaillée de 18 pages (que nous avons largement citée) comparant les approches des fournisseurs ⁴⁹ ²⁹ ²⁵, ainsi que des vidéos sur le fonctionnement de leurs algorithmes. Lorsqu’un fournisseur est secret sur comment fonctionne sa solution, on doit se demander si c’est parce qu’elle n’est pas vraiment spéciale. La transparence est corrélée à la crédibilité. Un fournisseur qui se cache derrière des mots à la mode et ne divulgue pas ses méthodes a probablement une “technologie ordinaire avec du rouge à lèvres en plus”.

En conclusion, l’application d’une lentille hautement sceptique, axée sur l’ingénierie révèle que de nombreux logiciels d’optimisation de la supply chain “leaders” sont riches en promesses et pauvres en innovation vérifiable. En coupant à travers le jargon marketing, nous nous sommes concentrés sur ce qui est tangible : les structures de données, les algorithmes, les performances et la preuve de l’efficacité. Les meilleures solutions se sont démarquées en offrant une substance technique - une précision de prévision démontrée, des choix architecturaux clairs et une documentation franche - tandis que les plus faibles se sont révélées à travers des contradictions, de la confusion et des bases obsolètes. Cette étude sert de rappel à tout praticien de la supply chain : ne prenez pas les affirmations des fournisseurs pour argent comptant. Exigez des preuves, regardez sous le capot et rappelez-vous que dans la supply chain, comme dans l’ensemble de l’informatique, les véritables avancées de pointe sont généralement étayées par une science ouverte et une ingénierie solide - et non pas seulement par des affirmations marketing grandioses.