Logiciel d'optimization de la Supply Chain, février 2025

Par Léon Levinas-Ménard

Dernière modification: le 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é pionnier de la prévision probabiliste et a prouvé ses méthodes en compétition ouverte (classé #1 au niveau SKU et #6 au total parmi 909 équipes dans le concours de précision de prévision M5 ¹ – la seule équipe dirigée par un fournisseur parmi les meilleurs). Lokad publie des analyses détaillées sur son architecture (par ex. un langage spécifique de domaine appelé Envision, automatisation basée sur le cloud) et met en avant des décisions financièrement optimisées plutôt que des métriques simplistes. Son accent sur des mathématiques rigoureuses (prévisions par quantiles, optimisation stochastique) et des workflows entièrement scriptables et automatisés (via APIs et codage) démontre une conception axée sur l’ingénierie. Aucune grande revendication en IA/ML n’est faite sans fondements – à la place, Lokad fournit des livres blancs techniques et même des outils open-source pour étendre le traitement des données au-delà des limites de la RAM ² ³. Ce niveau de transparence et de performance éprouvée place Lokad au sommet.
Anaplan – Plateforme “Excel 2.0”. Anaplan est essentiellement la version SaaS d’entreprise d’une feuille de calcul, propulsée par son moteur en mémoire propriétaire Hyperblock ⁴. Techniquement, Hyperblock est un moteur de calcul multidimensionnel robuste qui permet à des milliers d’utilisateurs de collaborer en temps réel sur des modèles de planification – comparable à un Excel basé sur le cloud suralimenté. Bien qu’Anaplan ne soit pas à proprement parler un optimiseur spécialisé de Supply Chain (la prévision et l’optimisation algorithmique sont des “citoyens de seconde zone” sur cette plateforme ⁵), sa force réside dans sa solide architecture pour la modélisation et la planification de scénarios. Il ne vend pas d’IA mystique ; au lieu de cela, il offre un bac à sable fiable et performant pour construire une logique de planification personnalisée. En bref, c’est un puissant outil général de planification avec une approche honnête – aucune revendication exagérée sur une magie de la prévision, juste un système de type feuille de calcul bien conçu et évolutif. Cette proposition technique claire confère à Anaplan un rang élevé en crédibilité.
Kinaxis (RapidResponse) – Moteur de simulation en mémoire. Kinaxis est réputé pour son moteur de concurrence unique qui permet de recalculer les plans de Supply Chain à la volée à travers l’entreprise. Techniquement, Kinaxis a développé son propre moteur de base de données de toutes pièces pour supporter cela ⁶ ⁷. Le résultat est une plateforme optimisée pour des fast “what-if” simulations : les utilisateurs peuvent créer des scénarios distincts (comme Git pour les données) et obtenir un retour instantané sur l’impact des changements ⁸. Le système conserve toutes les données de Supply Chain en mémoire pour la rapidité, les algorithmes ayant un accès direct à la mémoire pour un débit maximal ⁹. Cette conception permet une véritable planification concurrente (par exemple, les plans de vente, de production et de stocks mis à jour ensemble en temps réel). D’un point de vue ingénierie, construire un magasin de données personnalisé, en mémoire et contrôlé par version est un exploit impressionnant qui offre une grande agilité. L’inconvénient, cependant, est une forte exigence matérielle – une approche entièrement en mémoire signifie que l’extension à des tailles de données massives peut être coûteuse (à mesure que les exigences en RAM augmentent) ¹⁰. Dans l’ensemble, Kinaxis démontre une forte rigueur technique en termes d’architecture et de performance, tout en évitant les revendications à la mode en IA. Il excelle dans la planification d’approvisionnement et les simulations S&OP, bien qu’il propose moins de fonctionnalités de prévision ML prêtes à l’emploi comparé à certains de ses pairs.
SAS – Puissance statistique. SAS est une entreprise de logiciels d’analytique expérimentée (fondée en 1976) et apporte un formidable moteur de modélisation statistique aux problèmes de Supply Chain. Son produit phare inclut un langage spécifique au domaine pour la statistique (le langage SAS) datant des années 1970 ¹¹ – sans doute la plateforme originale 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, de routines d’optimisation et de techniques de machine learning développées sur des décennies. Elle emploie certains des ingénieurs et statisticiens les plus talentueux de l’industrie ¹¹, et a été pionnière dans la prévision avancée bien avant que “AI” ne devienne un mot à la mode. Dans le contexte de la Supply Chain, SAS est souvent utilisée pour la prévision de la demande et l’analyse des stocks. Techniquement, elle est robuste et éprouvée – mais aussi lourde. Les outils peuvent sembler archaïques (le monde s’est largement tourné vers des langages open-source comme Python/R, et en effet les notebooks Jupyter sont désormais une alternative ouverte supérieure ¹²). SAS ne revendique pas bruyamment une IA magique ; elle s’appuie sur sa réputation et sa technologie solide. Pour les organisations disposant de l’expertise pour l’exploiter, SAS offre une puissance analytique sérieuse fondée sur de vrais algorithmes (ARIMA, ETS, etc.) plutôt que sur du battage médiatique. Son principal inconvénient est qu’elle est une plateforme d’analytique générale – extrêmement puissante en interne, mais nécessitant des utilisateurs compétents pour l’appliquer à la Supply Chain, et elle n’a pas été spécifiquement évaluée dans des compétitions récentes de prévision (les outils open-source rivalisent souvent avec elle ¹³).
Dassault Systèmes (Quintiq) – Spécialiste de l’optimisation. Quintiq (acquis par Dassault Systèmes en 2014) est une plateforme focalisée sur l’optimisation et la planification complexes de Supply Chain. Elle offre un langage spécifique de domaine propriétaire appelé Quill pour modéliser les contraintes business ¹⁴. 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. La simple existence d’un DSL dans le produit témoigne d’une proficience deep-tech sérieuse – concevoir un langage de programmation pour des problèmes de planification n’est pas trivial ¹⁵. Quintiq excelle dans des scénarios tels que la planification en 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 Supply Chain. Cependant, la focalisation de Quintiq sur l’optimisation se fait au détriment d’autres domaines : par exemple, elle dispose de capacités natives de prévision relativement limitées ¹⁶. Une autre préoccupation est que les mises à jour techniques publiques sur Quill sont rares, ce qui laisse supposer 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 des besoins complexes d’optimisation et démontre une forte ingénierie via son DSL – mais elle n’est pas aussi transparente ou à la pointe dans des domaines comme l’IA/la prévision, et ses points forts résident dans ce que les implémenteurs en tirent plutôt que dans une « intelligence » prête à l’emploi.
ToolsGroup (SO99+) – Pionnier probabiliste avec réserves. Le logiciel de ToolsGroup (SO99+) est depuis longtemps spécialisé dans la prévision de la demande et l’optimisation des stocks, avec un accent sur les modèles probabilistes. Il offre une fonctionnalité étendue de Supply Chain (planification de la demande, réapprovisionnement, optimisation multi-échelons des stocks) et a été 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 « auto-réguler » les prévisions, ce qui devrait permettre des objectifs de stocks plus précis. Cependant, un examen technique approfondi soulève des préoccupations. Les documents publics de ToolsGroup laissent encore entendre qu’ils utilisent des modèles de prévision de l’ère pré-2000 en coulisses ¹⁸ – ils ont ajouté une touche d’« AI » dans leur marketing, mais sans détails. De façon significative, depuis 2018, ils font la promotion de prévisions probabilistes tout en se vantant simultanément d’améliorations du MAPE ¹⁹. Cela constitue une contradiction flagrante : si les prévisions sont réellement des distributions probabilistes, des métriques comme le MAPE (qui mesure l’exactitude d’une valeur unique) ne s’appliquent plus directement ¹⁹. De telles incohérences suggèrent que la partie « probabiliste » pourrait être superficielle ou qu’ils s’appuient sur d’anciennes métriques malgré de nouvelles méthodes. De plus, ToolsGroup a utilisé des mots à la mode comme « demand sensing AI », mais ces revendications sont non étayées par la littérature scientifique ou toute référence connue ²⁰. 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 résumé : ToolsGroup offre une fonctionnalité étendue et a été précurseur dans la promotion de la modélisation de l’incertitude, mais son manque de transparence concernant les algorithmes et l’écart entre le marketing et la réalité en matière d’IA/ML rendent sa crédibilité technique seulement modérée. C’est un ensemble d’outils solide et axé sur le domaine, mais qui n’est pas clairement à la pointe selon les standards actuels.
Slimstock (Slim4) – Direct et solide. Slimstock est un cas rafraîchissant qui ne suit pas les tendances. Son logiciel Slim4 se concentre sur les techniques de Supply Chain grand public – comme les calculs classiques de stocks de sécurité, les points de commande, la quantité économique de commande (EOQ), etc. ²¹. Autrement dit, 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 ou algorithmes de pointe, cela signifie aussi 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 correspondant aux 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 être une limitation – vous n’obtiendrez pas de prévisions probabilistes de la demande ni d’optimisateurs avancés avec Slim4. Il n’est pas conçu pour des réseaux hautement 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é prime si cela signifie que l’outil fonctionne de manière constante. Slimstock gagne des points de crédibilité pour avoir évité le jargon à la mode; son approche “directe” est saluée par ses pairs comme un contraste avec les postures en matière d’IA d’autres fournisseurs ²³. En résumé, Slim4 ne repousse pas les limites sur le plan technologique, mais c’est un choix judicieux pour une prévision fondamentale et une gestion des 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 des approvisionnements, 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 d’IA/ML. La masse technologique pure d’o9 est démesurée ²⁴ – 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, en adoptant un regard sceptique : une grande partie de cela semble être de la technologie pour le simple fait de la technologie, sans retour sur investissement clair. La conception en mémoire d’o9 garantit des coûts matériels extrêmement élevés à grande échelle ²⁵, comparable à faire fonctionner en continu un gigantesque cube BI. o9 vante son EKG (knowledge graph) comme permettant une meilleure prévision et des insights pilotés par l’IA, mais aucune preuve scientifique ou benchmark crédible n’est fourni ²⁵. En fait, beaucoup des revendications tape-à-l’œil d’o9 s’effondrent sous un examen minutieux : l’entreprise parle d’IA partout, pourtant des extraits de leur code publiquement visible sur GitHub révèlent des techniques plutôt banales ²⁶. Par exemple, o9 a fait la publicité de fonctionnalités telles que la prévision de la demande par machine learning et des simulations de “digital twin”, mais elle ne les a pas démontrées dans aucune compétition publique ni étude de cas évaluée par des pairs. Sans preuve, nous devons considérer ses revendications en IA comme du battage marketing. Cela dit, o9 n’est pas sans points forts – c’est une plateforme unifiée (conçue en interne, et non pas une amalgamation d’acquisitions) et elle peut gérer une 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 une flexibilité pour construire des modèles de planification complexes. Mais d’un point de vue ingénierie, c’est une solution sur-conçue : une grande complexité, un retour sur investissement peu clair pour la technologie sophistiquée, et des problèmes de performance potentiels si la quantité de données dépasse ce que la mémoire peut contenir.
SAP IBP (Integrated Business Planning) – Complet mais complexe. La suite IBP de SAP est l’évolution de l’APO historique de SAP, désormais proposée comme 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, sales & operations planning, et bien plus encore – le tout étroitement intégré avec l’ERP de SAP. La force de SAP IBP réside dans son ampleur : 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, cette ampleur résulte d’acquisitions et de systèmes hérités. SAP a acquis des spécialistes comme SAF (prévision de la demande), SmartOps (optimisation de stocks), et d’autres ²⁷, qu’il a superposés à ses outils internes (comme APO et HANA). Le résultat en coulisses est un patchwork de différents moteurs et approches ²⁷. En conséquence, l’architecture technique d’IBP n’est pas élégante – c’est un ensemble de composants qui ne s’imbriquent pas naturellement, nécessitant un effort d’intégration considérable. Même la documentation de SAP reconnaît la grande complexité et le besoin de systèmes d’intégrateurs de premier ordre (et d’un temps considérable) pour que tout fonctionne sans accroc ²⁸. Sur le plan technologique, IBP s’appuie fortement sur SAP HANA, une base de données en colonnes en mémoire, 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 coûteux (la RAM est environ 100 fois plus chère par To que le stockage sur disque) ¹⁰. Cela signifie que la mise à l’échelle d’IBP pour des ensembles de données de 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 propose 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’est apparu dans des compétitions de prévision indépendantes. 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éroclite : la rapidité en mémoire alliée à une logique héritée, beaucoup de complexité provenant 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 offraient déjà. Les entreprises le choisissent souvent pour son intégration avec l’ERP de SAP plutôt que pour une excellence en optimisation en soi.
Blue Yonder – Leader historique devenu patchwork. Blue Yonder (anciennement JDA Software) propose une suite complète couvrant la prévision, le supply planning, le merchandising et l’exécution. Il résulte de nombreuses années de fusions et acquisitions, y compris l’acquisition par JDA d’i2 Technologies (supply chain planning), de Manugistics, et de la startup AI Blue Yonder (dont il a adopté le nom) entre 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 fouillis de produits (dont beaucoup sont assez désuets) assemblés de manière approximative ²⁹. D’un point de vue technique, les solutions de Blue Yonder vont de moteurs de prévision déterministes à l’ancienne à des modules d’optimisation de stocks qui n’ont pas fondamentalement évolué depuis plus de 15 ans. L’entreprise met fortement en avant des capacités “AI” et “ML” dans 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 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 par des méthodes plus récentes. Il semble que l’AI tant vantée de Blue Yonder ne soit peut-être qu’un réemballage de régression et d’heuristiques. Faute d’études de cas transparentes ou d’articles techniques, on doit supposer que les revendications de Blue Yonder sur une “prévision AI révolutionnaire” ne sont que du vent marketing. De plus, l’intégration de tous ses composants acquis constitue un défi permanent – de nombreux clients signalent des difficultés à obtenir la promesse “end-to-end” parce que les modules (demande, supply, fulfillment, etc.) ne s’imbriquent pas naturellement sans personnalisations importantes. En mémoire ou sur disque ? Blue Yonder ne fait pas la promotion d’une architecture entièrement en mémoire comme d’autres ; certaines parties du système fonctionnent probablement sur des bases de données relationnelles standard. Cela peut en fait être un avantage en termes de coût, mais cela signifie également que les performances peuvent accuser un 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 une mise en garde : autrefois leader du secteur, il offre désormais une suite large mais techniquement incohérente. Ses forces résident dans son expérience sectorielle et une large gamme de fonctionnalités, mais ses faiblesses sont une technologie dépassée sous un vernis moderne et un manque de preuves crédibles pour ses nouvelles capacités “AI”.

(Remarque : D’autres fournisseurs comme Infor (avec des composants GT Nexus et Mercia hérités), 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 retail avec un moteur en mémoire), etc., existent également. Dans un souci de concentration, nous avons classé ci-dessus les exemples les plus en vue 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, de type cube OLAP – excellente pour la rapidité, mais garantissant un coût matériel élevé pour les grands détaillants ³¹ ; Infor a grandi par acquisitions menant à des problèmes d’intégration similaires à SAP/Blue Yonder ; GAINS et John Galt offrent une fonctionnalité de base solide mais peu de documentation publique sur des techniques innovantes. Tout fournisseur ne partageant pas ouvertement des détails techniques ou des preuves serait de toute façon classé bas dans 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 Supply Chain, en nous concentrant sur quatre domaines clés : prévision & AI, capacités d’automatisation, architecture système, et intégration des modules. Toute l’analyse repose sur des informations techniques publiées ou des preuves concrètes, en évitant explicitement tout langage marketing.

Capacités de Prévision & AI

La planification moderne de la Supply Chain repose sur la précision des prévisions de la demande, pourtant les affirmations de supériorité en matière de prévision foisonnent et sont 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é des mots à la mode tels que “AI” ou “machine learning” dans leur marketing.

Performance Prouvée vs. Battage médiatique : Parmi tous les fournisseurs, Lokad est le seul à disposer d’un palmarès vérifiable de prévision de classe mondiale, grâce à la compétition ouverte M5. Lokad a démontré sa maîtrise de la prévision probabiliste en se classant en tête en termes de précision au niveau des SKU ¹. Cela donne de la crédibilité aux affirmations de Lokad concernant une meilleure précision des 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 revendiquant une précision supérieure, pourtant ces méthodes étaient absentes des premières places de la compétition M5 ³². En pratique, les approches académiques open-source (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 sur une “précision de prévision inégalée dans l’industrie” sans preuve publique doit être considérée comme non étayée.
Affirmations sur l’AI et le Machine Learning : Nous avons fait preuve d’un scepticisme extrême face au battage médiatique autour de l’AI/ML. Des fournisseurs tels que o9 Solutions et Blue Yonder utilisent abondamment des termes comme “prévision pilotée par AI/ML” dans leurs brochures. Cependant, en recherchant du concret, nous avons trouvé peu de preuves. Dans le cas d’o9, leurs affirmations selon lesquelles le “Enterprise Knowledge Graph” basé sur les graphes produit de meilleures prévisions sont douteuses et ne reposent sur aucune base scientifique ²⁵. Blue Yonder vante également l’AI sans fournir de détails – 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 ordinaires (ARMA, régression linéaire, ingénierie des caractéristiques) ³⁰. Il n’y a aucune preuve de deep learning, de méthodes probabilistes avancées ou d’une autre AI moderne justifiant 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 paritaire ou victoire en compétition pour le valider ²⁰. En fait, l’association par ToolsGroup de la “prévision probabiliste” avec de vieux indicateurs comme le MAPE suggère que leur AI est plus du battage que de la percée ¹⁹. Conclusion : Mis à part Lokad (et dans une certaine mesure SAS, qui utilise des modèles statistiques éprouvés), la prévision dans la plupart des logiciels de Supply Chain repose toujours sur des méthodes connues (lissage exponentiel, régression, peut-être quelques algorithmes basés sur les arbres) et non sur une AI géniale propriétaire. Les fournisseurs disposant d’algorithmes réellement novateurs les démonstreraient 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 se cantonne aux prévisions ponctuelles. Lokad est depuis 2012 un fervent défenseur des distributions de probabilité complètes, 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 Monte Carlo de la demande). Cependant, nous avons constaté que beaucoup de ceux qui prétendent être “probabilistes” reviennent en réalité à des métriques et processus déterministes en interne. Par exemple, le marketing de ToolsGroup sur la réduction du MAPE grâce à l’utilisation de 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 ultimement sur une prévision ponctuelle (moyenne ou médiane) pour l’évaluation, annulant ainsi l’avantage probabiliste. D’autres fournisseurs comme SAP, Oracle, Blue Yonder ont commencé à mentionner des termes probabilistes (SAP IBP dispose désormais de “groupes statistiques” et d’intervalles de confiance), mais encore une fois, leurs interfaces utilisateur et rapports se limitent souvent à des prévisions en un seul nombre avec des métriques d’erreur traditionnelles. Adopter une véritable prévision probabiliste nécessite de repenser les KPI (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, à l’exception de Lokad, soit allé aussi loin en pratique. En résumé, la prévision probabiliste est un domaine où le marketing précède la réalité pour la plupart des fournisseurs – ils peuvent générer quelques distributions en coulisses, mais les planificateurs se contentent encore de regarder des chiffres de prévision ponctuels et des KPI classiques, ce qui indique une adoption limitée du paradigme.
Métriques de Prévision et Évaluation : Un aspect important de la rigueur technique est la manière dont un fournisseur évalue la qualité des prévisions. Un signe d’alerte est la dépendance continue à des métriques telles que MAPE, 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 une prévision conservatrice et centrée, et peuvent être manipulées (par exemple, en supprimant les valeurs extrêmes). Nous avons observé que les fournisseurs disposant de prévisions véritablement 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 se contenter 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 bien d’autres mettent encore en avant les erreurs en pourcentage dans leurs études de cas, montrant une mentalité désuète. Si la documentation ou la démo d’un fournisseur présente massivement des tableaux de bord MAPE/WAPE, c’est le 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 : une prévision véritablement de pointe en Supply Chain serait attestée par des métriques probabilistes et une validation en conditions réelles – des attributs largement absents 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 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’un des atouts majeurs de Lokad. L’ensemble de la solution est construit autour d’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, qui s’exécutent ensuite automatiquement selon un planning. Lokad documente clairement ses pipelines de données et son gestionnaire de workflow qui actualisent les données et recalculent les décisions (prévisions, ordres de réapprovisionnement, etc.) sans intervention manuelle ³⁴ ³⁵. Ils évoquent même avoir des configurations hautement automatisées pour environ 100 Supply Chains en production ³⁵, ce qui signifie que le logiciel récupère les données, effectue des prévisions et génère des décisions (comme des propositions d’ordres d’achat) de manière autonome. De plus, Lokad fournit des API pour le téléchargement des données et des résultats, et possède un concept “AI Pilot” pour automatiser les tâches administratives ³⁶. Tout cela indique un très haut niveau d’automatisation véritable – le rôle de l’utilisateur se limite 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 du manuel à l’automatisé ³⁷ ³⁸).
Kinaxis: Kinaxis RapidResponse est conçu pour une analyse rapide des scénarios et la collaboration plutôt que pour une planification entièrement automatisée. Le concept de “planification concurrente” consiste à ce que tout le monde travaille sur le même jeu de données avec des mises à jour en temps réel, mais il implique généralement 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 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 APIs et dispose d’un système de scripting (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 les commandes. Le fournisseur ne clame pas haut et fort une “supply chain autonome” ; au contraire, il se concentre sur l’efficacité accrue des planificateurs. C’est une position honnête. Cela signifie que pratiquement, 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 “self-driving”. Techniquement, Kinaxis peut être intégré de manière approfondie (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 basées sur l’IA (sa force réside davantage dans le calcul rapide des 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 pouvant formuler des recommandations. Ils évoquent “Automation” dans le contexte de leurs assistants numériques – vraisemblablement des bots capables de mettre en lumière 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 dans quelle mesure ces affirmations sont réelles. Nous n’avons trouvé aucune précision telle que “o9 peut automatiquement libérer des commandes de réapprovisionnement via API en se basant sur ses plans” ou “o9 utilise l’apprentissage par renforcement pour ajuster ses paramètres lui-même.” Le manque de précision dans l’histoire d’automatisation d’o9 est préoccupant : beaucoup de discours de haut niveau, mais peu de détails. Étant donné sa fondation basée sur la mémoire interne, nous soupçonnons qu’o9 est capable de mises à jour de données en temps réel et de recalculs, mais il dépend probablement toujours des utilisateurs pour configurer ce qu’il faut faire avec ces informations. Sans références crédibles, nous considérons les affirmations d’“autonomie” d’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 par API devrait exister), mais le degré d’automatisation decisionnelle par l’IA dans o9 reste obscur. Les éléments de preuve suggèrent que l’automatisation actuelle d’o9 consiste davantage à accélérer l’analyse (par exemple, des scénarios “what-if” instantanés) qu’à automatiser les résultats décisionnels.
Blue Yonder: Ces dernières années, Blue Yonder (notamment depuis son acquisition par Panasonic) a promu le terme “autonomous supply chain”, impliquant un système pouvant 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, étant donné le noyau hérité de Blue Yonder, il est probable que toute autonomie soit obtenue en superposant de la RPA (Robotic Process Automation) ou de simples agents IA sur des modules existants. Par exemple, la planification de la demande de Blue Yonder pourrait produire une prévision, et une couche “AI” pourrait l’ajuster automatiquement en fonction des ventes en temps réel (détection de la demande) ou envoyer une alerte en cas de déviation. Mais la planification entièrement automatisée (comme la génération automatique des commandes, l’ajustement automatique des politiques de stocks) est probablement rare avec les solutions de Blue Yonder – les clients font généralement encore vérifier et approuver les actions par des planificateurs. Le manque de documentation 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 blogs techniques à ce sujet. Au lieu de cela, ils se contentent essentiellement de webinaires marketing. Nous en déduisons donc que Blue Yonder permet un certain degré d’automatisation (comme des tâches par lots, des mises à jour de plans, voire une intégration en boucle fermée aux systèmes d’exécution), mais il n’est pas démontré comme étant en avance dans ce domaine. Il utilise probablement une planification basée sur les exceptions similaire aux anciens systèmes (simplement avec une nouvelle patine IA sur le système d’alerte).
ToolsGroup: ToolsGroup s’est historiquement vanté de sa “Powerfully Simple Automation.” Ils affirmaient que leur système pouvait fonctionner en mode lights-out pendant des périodes prolongées, n’appelant des planificateurs qu’en cas d’exception. En effet, la philosophie de ToolsGroup était de laisser le système reforecaster 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 stocks et recommande des commandes. ToolsGroup dispose également d’un kit d’intégration pour transmettre les commandes approuvées aux systèmes ERP. Cependant, en raison des contradictions précédemment notées, nous avons des doutes quant à l’intelligence de cette automatisation. Il se pourrait que le système applique simplement la même formule chaque jour et signale lorsque quelque chose cloche (gestion des exceptions). ToolsGroup fournit une API et prend en charge des exécutions planifiées, donc techniquement, l’infrastructure pour l’automatisation est présente. La question demeure quant à la qualité des décisions automatisées. Ils mentionnent souvent “self-tuning” – impliquant que le logiciel ajuste lui-même les paramètres du modèle de prévision à mesure que de nouvelles données arrivent ³⁹. Si cela est vrai, c’est une automatisation utile (éliminant le besoin d’une reconfiguration humaine constante). Sans évaluation indépendante, nous dirions prudemment que ToolsGroup offre une automatisation élevée 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 et s’améliore-t-elle véritablement, 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 standard : intégration de données via des APIs ou par traitement de fichiers par lots, exécutions planifiées de la planification et certains workflows 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 le résultat. Anaplan est moins axé sur l’automatisation – il s’agit davantage d’une plateforme de modélisation manuelle, bien qu’il soit possible d’utiliser son API pour pousser ou extraire des données et peut-être automatiser certains calculs. Dassault/Quintiq peut être scripté pour exécuter des routines d’optimisation selon un planning (et le DSL de Quintiq signifie que vous pouvez programmer des comportements automatiques personnalisés), mais encore une fois, son degré d’autonomie dépend de la programmation de l’implémenteur. GAINS, Relex, Netstock et d’autres fournisseurs de niche font la promotion de “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 de magasin. La principale différence réside dans le degré de supervision requis : un véritable système de planification autonome n’appellerait des humains que pour des situations inhabituelles et documenterait ses décisions avec des justifications. Nous n’avons trouvé aucun fournisseur qui réalise pleinement cet idéal à ce jour. Soit ils nécessitent que des humains ajustent et approuvent (dans la plupart des cas), soit ils n’automatisent que 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 continuent de compter sur les humains pour finaliser le processus. Nous notons également que certains fournisseurs ont, au cours des dernières décennies, déplacé leur focus de l’automatisation complète vers la “gestion des exceptions” – ce 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 assez robuste pour être entièrement 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, quelles API), alors son “automatisation” relève probablement du simple discours marketing.

Architecture du système & Scalabilité

La conception sous-jacente – en particulier l’utilisation du calcul en mémoire versus sur disque, ainsi que les choix globaux de conception – a d’énormes implications sur 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 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 l’intégralité 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 des 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 ⁹. SAP HANA a été conçu sur la base de l’idée 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 en mémoire : le coût et la scalabilité. La mémoire (RAM) est extrêmement chère 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 physiquement limitée (les systèmes typiques disposent de 0,5 à 2 To de RAM au maximum, alors que des ensembles de données de plusieurs téraoctets ou pétaoctets sont fréquents dans les grandes supply chains). Ces dernières années, les baisses drastiques prévues du coût de la RAM ne se sont pas matérialisées – les prix et capacités de la RAM sont restés assez stagnants ⁴². Cela signifie que tout système exigeant que l’ensemble des données soit en mémoire fera face à des coûts d’infrastructure en explosion au fur et à mesure que les données augmentent, ou atteindra une limite infranchissable où il ne pourra tout simplement pas contenir les données. Nous qualifions cette forte dépendance à une conception en mémoire d’erreur architecturale pour les grandes supply chains, sauf si elle est atténuée.
Mémoire vs. Disque : Pratiques Modernes : Fait intéressant, le monde technologique a réalisé que les solutions purement en mémoire ne représentent pas l’avenir pour le big data. Les architectures plus récentes utilisent une approche hiérarchisée – conserver les données “chaudes” en mémoire et les données “froides” sur SSD, etc. ⁴³ ⁴⁴. Certains logiciels de 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 ensemble de données de vente au détail comportant 10 milliards de lignes en utilisant environ 37 Go de RAM, complétés par un SSD NVMe rapide pour absorber les débordements ⁴⁵ ³. Ils atteignent des performances proches de celles de la RAM en mappant les fichiers en mémoire et en ne gardant que les données les plus sollicitées en RAM, le logiciel procédant intelligemment à des échanges lorsque nécessaire ⁴⁶ ⁴⁷. 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 ³, 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 gestion adaptative de la mémoire de ce type, ce qui suggère que leurs solutions pourraient tout simplement exiger beaucoup de RAM ou nécessiter une agrégation des données pour pouvoir tenir. 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 leurs modèles. Kinaxis a probablement également besoin de plusieurs serveurs interconnectés pour traiter des données très volumineuses (ils disposent d’un concept de distribution des données, mais au sein de chaque nœud, elles résident en mémoire). SAP HANA peut décharger des données sur disque (elle 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 des données de petite à moyenne taille, mais à mesure que la supply chain s’agrandit (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 favorise un mélange d’utilisation de la mémoire et du disque pour équilibrer vitesse et coût, et les fournisseurs qui ne le font pas sont à la traîne.
Pile Technologique et Complexité : Au-delà de la mémoire, un autre élément architectural est l’ensemble de la pile technologique – monolithique vs. microservices, utilisation de langages de programmation modernes, etc. Sans entrer trop dans les détails, nous avons observé que les fournisseurs plus anciens (SAP APO/IBP, Blue Yonder) fonctionnent avec des piles plus monolithiques et héritées, tandis que les plus récents (o9, Anaplan) ont bâti leur solution de toutes pièces avec des technologies modernes. Par exemple, le cœur de SAP IBP 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 un potentiel d’inefficacité (multiples couches d’abstraction). Blue Yonder comporte également 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 l’ont continuellement remanié dans leur propre noyau de base de données ; néanmoins, il s’agit d’une pile propriétaire qu’eux seuls utilisent. Anaplan a développé 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, l’absence de requêtes SQL, une complexité algorithmique limitée puisque les calculs se font principalement au niveau des cellules). La plateforme d’o9 comprend un mélange de technologies (probablement une base de données NoSQL/graph, peut-être Spark ou similaire pour certains aspects de ML, etc.), ce qui la rend complexe mais théoriquement flexible.
Matériel et Cloud : Une tendance notable est le design cloud-native. De nombreux fournisseurs proposent désormais leurs logiciels en SaaS ou, du moins, en mode hébergé dans le cloud, mais tous ne sont pas véritablement cloud-native. Par exemple, Anaplan et o9 sont des SaaS multi-locataires (conçus dès le départ pour le cloud). Lokad est nativement cloud (il fonctionne sur Microsoft Azure et alloue dynamiquement les ressources). SAP IBP est hébergé dans le cloud mais, en réalité, chaque client se voit attribuer 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 leurs logiciels on-premises gérés depuis le cloud. Pourquoi cela est-il important techniquement ? Les architectures cloud-native sont généralement plus élastiques – elles peuvent déclencher des ressources de calcul lorsque nécessaire (pour une grande session de planification) et les désactiver ensuite, permettant ainsi de contrôler les coûts. Les systèmes non cloud requièrent souvent d’acheter en capacité de pointe même s’ils ne sont utilisés qu’occasionnellement. De plus, les systèmes cloud-native s’intègrent mieux avec d’autres services cloud (par exemple, se connecter à un service ML cloud ou à un data lake). D’après nos observations, les solutions les plus cloud-native et conçues pour être évolutives semblent être Lokad et o9 (et peut-être Anaplan), tandis que d’autres rattrapent leur retard. Cependant, être cloud-native à lui seul n’équivaut pas à une bonne architecture – o9 est cloud-native, mais nous avons remis en question son approche fortement axée sur l’in-memory ; le fait que SAP IBP soit sur cloud ne résout pas ses problèmes de complexité.
Concurrency et besoins en temps réel : Une considération architecturale est la manière dont le système gère les utilisateurs concurrents et les mises à jour en temps réel. Kinaxis excelle ici : il a été construit pour permettre à plusieurs planificateurs de réaliser simultanément des scénarios sur le même jeu de données. Cela nécessite une gestion minutieuse des versions de données et une logique de verrouillage – que Kinaxis a réalisée via leur mécanisme de branchement ⁸. La plupart des autres outils suivaient traditionnellement un paradigme par lots (planifier, publier, puis collaborer séparément). Aujourd’hui, beaucoup ajoutent des fonctionnalités de planification simultanée. Anaplan permet à plusieurs personnes de travailler dans différentes parties du modèle à la fois (puisque c’est essentiellement basé sur des cellules comme Google Sheets). SAP IBP a introduit une interface utilisateur de type “Microsoft Excel” qui peut rafraîchir les données à la demande depuis le serveur, mais la véritable concurrence (plusieurs utilisateurs éditant simultanément le même plan) est limitée. o9 supporte probablement 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 véritablement 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 architectures plus anciennes rendent cela difficile – entraînant soit une performance lente, soit l’imposition de processus séquentiels.

Résumé pour 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 (Lokad’s spill-to-disk, peut-être les outils utilisant des bases de données modernes) sont plus évolutives et économiquement rentables. Un signal d’alarme clair est tout fournisseur insistant sur le fait que tout doit être en RAM pour fonctionner – ceci est désormais considéré comme une approche dépassée vu les progrès en vitesse des SSD et en informatique distribuée ⁴³ ⁴⁴. Nous soulignons également que l’architecture d’un fournisseur issu de multiples acquisitions (comme SAP, Blue Yonder) tend à être excessivement complexe et nécessite beaucoup de réglages. Des architectures plus simples, développées en interne (le code source unique de Kinaxis, le moteur unique d’Anaplan, le moteur unique de Lokad) tendent à être plus cohérentes et donc plus faciles à maintenir techniquement. En évaluant un logiciel de supply chain, on devrait se demander : Le fournisseur a-t-il publié des informations sur la manière dont son logiciel est construit (microservices ? base de données personnalisée ? utilisation de bibliothèques ML ? etc.). L’absence de toute discussion d’ingénierie pourrait signifier que l’architecture n’est qu’une boîte noire – indiquant souvent du legacy ou un manque de confiance dans leur caractère unique.

Intégration & cohérence des modules (Impact des F&A)

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

Blue Yonder (JDA) est l’exemple par excellence de la croissance par acquisition. Comme noté, c’est une « collection hâtive » de produits issus d’époques différentes ²⁹. JDA a acquis i2 (qui lui-même comportait plusieurs modules), a acquis Manugistics auparavant, puis RedPrairie (pour la gestion d’entrepôt), puis la startup Blue Yonder pour l’IA. Chaque composant avait son propre schéma de base de données, sa propre logique. Le résultat : encore aujourd’hui, la prévision de la demande, la planification de l’offre et l’optimisation de stocks de Blue Yonder pourraient ne pas partager un modèle de données unifié – l’intégration repose sur des interfaces. Ceci est un signal d’alerte car cela signifie que la mise en œuvre de la suite complète revient essentiellement à intégrer plusieurs paquets logiciels distincts. Lorsque les produits d’un fournisseur ne sont pas véritablement unifiés, les clients font face à des problèmes comme 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 manières de faire la planification de stocks – l’une issue du Manugistics hérité et l’autre issue d’i2). La société a fourni 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 des entreprises fusionnent ²⁹ – cela prend des années de réingénierie. Nous n’avons pas vu de preuve que Blue Yonder ait achevé cette réingénierie. Ainsi, le manque de cohérence constitue 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 ²⁷. Les utilisateurs ont noté qu’IBP possède différents modules qui ressemblent à 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 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 le tout sur la base de données HANA), mais malgré tout, dans les coulisses, IBP n’est pas un code source unique. SAP avertit explicitement que la mise en œuvre d’IBP nécessite habituellement plusieurs années et des intégrateurs experts pour faire fonctionner tous les modules ensemble de manière optimale ²⁸. Cette affirmation est un signal d’alerte en soi – elle implique un potentiel déséquilibre et une complexité.
Infor (bien qu’il ne figure pas dans le top 10 ci-dessus) a également fusionné divers systèmes de planification (ils avaient acquis la planification de supply chain de Mercia et GT Nexus, etc.). Le résultat n’a jamais été une plateforme de planification véritablement 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é 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 et de la planification. Ainsi, la cohérence interne de Quintiq est bonne (elle a été développée en interne et le demeure), mais l’inconvénient est qu’elle ne couvre pas tous les domaines (par exemple, il n’y a pas de prévision native de la demande, comme noté ¹⁶). Le portefeuille de Dassault comporte 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 autocohérente mais fonctionnellement limitée. Du point de vue de l’utilisateur, il se peut que vous deviez l’intégrer avec un autre outil de prévisions, ce qui signifie un travail supplémentaire pour le client.
Kinaxis a surtout crû organiquement – 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 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 la configuration. Cette cohérence est un atout : tous les modules (demande, offre, stocks) partagent une même base de données et une interface utilisateur dans Kinaxis. De même, Anaplan a développé différentes « apps » de planification sur une plateforme unique – les plans des ventes, des finances, et de la supply chain résident tous dans le même environnement Hyperblock, ce qui est techniquement très cohérent (seulement des modèles de templates 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 crû par l’acquisition d’autres fournisseurs de planification, du moins pas des grands). Ainsi, ces trois – Kinaxis, Anaplan, o9 – bénéficient d’un avantage architectural en termes d’unité. La prudence avec eux ne concerne pas l’intégration des modules disparates, mais bien de savoir si leur plateforme unique peut véritablement gérer la profondeur de chaque domaine.
ToolsGroup & Slimstock : Ces fournisseurs sont restés concentrés sur leur créneau (la planification de la demande et des stocks). Ils n’ont pas vraiment acquis d’autres entreprises ; au lieu de cela, ils se sont associés ou intégrés avec des systèmes d’exécution selon les besoins. Cela signifie que leur logiciel est internement cohérent (une seule base de code), ce qui est bien, 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 du 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 – l’enjeu est de savoir si leur conception à focale unique couvre suffisamment les besoins de l’utilisateur.

Résumé pour l’intégration : D’un point de vue sceptique, de nombreuses acquisitions majeures dans l’histoire d’un fournisseur sont un signe d’alerte. Cela conduit souvent à un produit touche-à-tout qui n’excelle 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 d’assembler de nombreux éléments hérités. À l’inverse, les fournisseurs disposant d’une plateforme unifiée (construite de manière organique) évitent ces problèmes, même s’ils doivent encore prouver qu’une plateforme peut tout faire correctement. Lors de l’évaluation d’un logiciel, il faut 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 de sociétés d’origine différentes, examinez la manière dont ils partagent les données et si l’intégration est fluide ou basée sur des interfaces. L’histoire a montré que, sauf si la technologie acquise a été réécrite 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. Nos recherches renforcent 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 les notes les plus faibles (Blue Yonder, Infor) ont accumulé des technologies disparates sans les unifier complètement.

Faiblesses critiques & signaux d’alarme

Dans notre analyse rigoureuse, nous avons identifié plusieurs faiblesses récurrentes et signaux d’alarme dont les utilisateurs potentiels doivent être conscients. Vous trouverez ci-dessous un résumé des problèmes clés, avec des exemples de fournisseurs spécifiques pour illustrer chaque point :

Revendications non étayées en “AI/ML” : Soyez extrêmement sceptique à l’égard de tout fournisseur proclamant une supériorité en matière d’IA ou de machine learning sans preuves techniques solides. Par exemple, Blue Yonder fait beaucoup de publicité pour l’IA mais ne fournit que des revendications vagues sans substance ³⁰ – ce peu 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 sur l’IA” avec seulement des analyses banales en réalité ²⁶. Si un fournisseur ne peut pas se référer à des études évaluées par des pairs, des brevets, des compétitions ou des articles techniques détaillés pour appuyer ses revendications sur l’IA, supposez qu’il s’agit de vantardise marketing. Les fournisseurs véritablement avancés seront fiers de détailler leurs algorithmes.
Absence d’étalonnage concurrentiel (revendications de supériorité en prévision) : De nombreux fournisseurs affirment offrir une “précision de prévision best-in-class” mais aucun à part Lokad ne l’a prouvé dans des compétitions ouvertes ou publications. Nous traitons toute telle revendication comme fausse à moins qu’elle ne soit validée. Par exemple, l’algorithme propriétaire d’un fournisseur vanté comme “plus précis que les autres” était absent du classement des mieux placés du concours M5 ³², ce qui suggère fortement que leur revendication 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évisions. C’est un signal d’alerte majeur : cela implique que ces fournisseurs soit n’ont pas participé (peut-être pour éviter une gêne publique) soit ont participé et ont mal performé. Conseil pratique : Exigez de voir des résultats objectifs d’exactitude (par exemple, comment leur outil a-t-il performé sur un étalon standard comme les ensembles de données M5 ou M4) – s’ils ne peuvent fournir rien, ne vous laissez pas séduire par le battage médiatique.
Dépassement de l’architecture in-memory : Les fournisseurs prônant une conception entièrement basée sur la mémoire devraient être interrogés sur la scalabilité et le coût. L’informatique in-memory 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 in-memory non évolutives et coûteuses pour de grands volumes de données. SAP IBP (HANA) et o9 en sont des exemples : ils garantissent une haute performance uniquement si vous chargez d’énormes ensembles de données en mémoire, ce qui garantit des factures matérielles (ou cloud) élevées ²⁴ ³¹. Il est significatif que la conception des systèmes modernes s’éloigne de cette approche – comme le souligne un expert, la frénésie initiale de tout mettre en RAM a atteint des limites pratiques, et les bases de données « retrouvent leur attrait pour le disque » pour gérer efficacement les données froides ⁴³ ⁴⁴. Si un fournisseur reste bloqué sur une mentalité exclusivement in-memory, considérez cela comme un signal d’alarme architectural. Les fournisseurs plus évolutifs évoqueront le stockage hiérarchisé, l’élasticité cloud ou des stratégies similaires pour gérer de grandes quantités de données 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âtif de produits datés dû à une longue série de fusions ²⁹, et les modules d’SAP IBP proviennent de différentes sociétés acquises ²⁷, entraînant une complexité et une “collection” d’outils plutôt qu’un ensemble cohérent. Les logiciels d’entreprise ne se “mélangent” pas aisément à travers les F&A ²⁹ – à moins que le fournisseur n’ait procédé à une réingénierie complète (ce qui est rare et long), le client se retrouve souvent à agir en tant qu’intégrateur entre les modules. Cela peut signifier 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 par le fournisseur nécessite un bataillon de consultants pendant un an ou plus pour faire communiquer les modules – comme même reconnu dans le cas de SAP ²⁸. Privilégiez les fournisseurs avec une plateforme unifiée ou un chevauchement minimal dans les composants acquis.
Métriques contradictoires et buzzwords : Un signal d’alarme subtil mais révélateur se manifeste 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 publicité de prévisions probabilistes tout en référant simultanément à des améliorations de MAPE ¹⁹ – un signe qu’ils ne font qu’ajouter une nouvelle terminologie à d’anciennes pratiques (puisque l’utilisation du MAPE pour juger des prévisions probabilistes est conceptuellement erronée). Un autre exemple concerne des fournisseurs qui prétendent utiliser une « IA avancée » mais qui mesurent ensuite le succès avec d’anciennes métriques comme le MAPE ou des taux de service traditionnels – ce qui 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 affirmer optimiser les stocks avec l’IA, mais si vous examinez de près et constatez qu’il calcule encore le stock de sécurité selon une formule datant des années 80 (p. ex. en supposant une distribution normale avec un facteur de sécurité statique), c’est une contradiction. Nous avons en effet relevé des cas où des fournisseurs parlent d’un stock « probabilistic » ou « optimal », alors que leur documentation révèle des calculs standards de stock de sécurité et l’utilisation d’anciennes métriques comme le taux de remplissage. Conclusion : Les incohérences entre ce qu’ils commercialisent et ce qu’ils mesurent/fournissent sont un signal d’alarme. Si un fournisseur se vante d’être moderne et axé sur l’IA, tout en utilisant les mêmes indicateurs clés de performance 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 progressé (p. ex. du déterministe aux modèles stochastiques, de l’optimisation à un seul échelon à l’optimisation multi-échelons), mais certains logiciels n’ont pas suivi. La dépendance à 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 du 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 en sont transparents, 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 faisaient référence à des modèles ARMA ⁴⁸, qui sont des techniques de prévision des années 1970, alors même que leur dossier commercial parle d’IA. Infor, Oracle, John Galt et d’autres acteurs de niveau inférieur s’appuient souvent sur des méthodes de prévision des séries temporelles et des heuristiques qui existent depuis toujours (comme le lissage exponentiel de Winters ou des solveurs d’optimisation simples) – ces méthodes fonctionnent, mais elles ne sont pas modernes. Le signal d’alarme n’est pas tant l’utilisation de méthodes anciennes (ces méthodes peuvent parfois être les meilleures), c’est de les utiliser tout en prétendant être innovant ou de les utiliser de façon exclusive alors que de meilleures méthodes existent pour le problème. Interrogez toujours sur les algorithmes réellement utilisés (p. ex., « Est-ce que votre optimisation de stocks prend en compte l’ensemble de la distribution de la demande ou seulement un seul facteur de service ? Utilisez-vous l’optimisation multi-échelons ou simplement des calculs par nœud unique ? »). Des réponses évasives ou vagues indiquent que la méthodologie pourrait être dépassée.
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 explication des algorithmes – c’est en soi un signe d’avertissement. Dans notre recherche, les fournisseurs qui ont obtenu de bons scores sur le plan technique (Lokad, Kinaxis, SAS, etc.) disposent au moins d’un contenu technique (qu’il s’agisse de blogs, d’articles académiques ou de notes techniques). Les fournisseurs ayant obtenu de faibles scores n’offrent 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 quasiment impossible, vous n’obtenez principalement que des brochures soignées. 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 reste secret sur la manière dont sa solution fonctionne, il faut se demander si ce n’est pas parce qu’elle n’est pas réellement spéciale. La transparence est corrélée à la crédibilité. Un fournisseur qui se cache derrière des buzzwords sans dévoiler ses méthodes possède vraisemblablement une « technologie ordinaire avec une couche de fard ».

En conclusion, appliquer une approche hautement sceptique et axée sur l’ingénierie révèle que de nombreux logiciels « leading » d’optimization de la supply chain regorgent de promesses mais manquent d’innovation vérifiable. En dépassant les fioritures 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 distinguaient en offrant une substance technique – précision de prévision démontrée, choix architecturaux clairs et documentation sincère – tandis que les solutions moins performantes se révélaient par leurs contradictions, leur vague description et des fondements obsolètes. Cette étude rappelle à tout praticien de la supply chain de ne pas prendre les revendications des fournisseurs pour argent comptant. Exigez des preuves, examinez le fonctionnement interne, et rappelez-vous que dans la supply chain, comme dans toute l’informatique, les véritables avancées de l’état de l’art sont généralement soutenues par la science ouverte et une ingénierie solide – et non par de hautes revendications marketing.