Une revue de "How Generative AI Improves Supply Chain Management"

Joannes Vermorel

The Harvard Business Review, dans son numéro de janvier-février 2025, a récemment publié How Generative AI Improves Supply Chain Management¹ par Ishai Menache (Microsoft), Jeevan Pathuri (Microsoft), David Simchi-Levi (Professor, MIT), et Tom Linton (McKinsey). Comme le suggère le titre, l’article fournit une série d’exemples censés illustrer comment les LLMs (large language models) peuvent contribuer à la gestion de la supply chain. Considérant la liste d’organisations d’élite (Microsoft, McKinsey, MIT, et même Harvard) impliquées dans la publication de cet article, on pourrait s’attendre à des points de vue profonds et perspicaces — du genre qui expliquent en détail comment une technologie brillante — les LLMs — va contribuer à l’amélioration des supply chains.

Au lieu de cela, nous obtenons une contribution médiocre. Plus précisément : elle est paresseuse, hyperbolique et profondément erronée — un article qui se contente de surfer sur un mot à la mode technologique. Toute la prémisse de l’article peut se résumer par Les LLMs peuvent à la fois générer et expliquer du code pertinent pour la supply chain. Les auteurs adoptent ce que j’appelle généralement une approche gadgetoïde du sujet. Cette approche gadgetoïde consiste, lors de la découverte d’une nouvelle technologie, à l’installer hâtivement dans un système existant. Cela se fait typiquement sans aucune considération des limitations de la technologie ou des changements qu’elle entraînerait dans le système. En conséquence, cette approche produit invariablement des gadgets — des outils amusants d’intérêt limité — et aucune valeur commerciale.

Aux différentes organisations impliquées :

• Microsoft : vous avez de nombreux ingénieurs talentueux à bord. Vous devez vous tenir à des normes plus élevées.

• McKinsey : ne dirigez pas des clients potentiels vers des voies qui sont garanties de leur faire perdre temps et argent.

• MIT et Harvard : vous devriez être des voix de la raison et ne pas amplifier les balivernes des fournisseurs technologiques.

Clarifions immédiatement que, bien que je convienne que les LLMs puissent être utilisés pour l’amélioration des supply chains, ils peuvent également être une distraction totale — selon la manière dont l’initiative est abordée. Ce point constitue exactement le problème fondamental qui affecte l’article en revue. Un article étroitement lié de Microsoft² souffre également de ce problème ; bien que, pour plus de clarté, ma critique restera centrée sur l’article de Harvard.

Avant d’aborder les absurdités technologiques de fond, signalons un problème éthique notable. Cet article n’est rien d’autre qu’une publicité déguisée pour Microsoft Cloud Supply Chain. Microsoft est naturellement libre de promouvoir ses services comme il l’entend, mais associer Harvard (par le biais de la publication) et le MIT (par le biais de la co-rédaction) à un article promotionnel me déplaît profondément. Au minimum, l’article devrait signaler que les coauteurs ont des conflits d’intérêts évidents. Le monde académique ne devrait pas cautionner une activité promotionnelle dissimulée de la part des vendeurs de technologie, quelle que soit leur taille ou leur influence.

Avertissement: Le lecteur averti se rendra compte que j’ai également un conflit d’intérêts. Oui, je dirige une entreprise de logiciels supply chain et, par conséquent, j’ai un intérêt personnel à contredire les absurdités propagées par Microsoft, McKinsey, MIT et Harvard. Je mets maintenant toutes mes cartes sur la table.

Passons maintenant à une critique des affirmations avancées par l’article.

Les planificateurs surveillent également, sur une base mensuelle, les modifications du plan de demande, appelé le décalage de demande, afin de s’assurer que le plan révisé satisfait à toutes les exigences des clients et respecte les directives budgétaires […] La technologie basée sur les LLMs accomplit désormais tout cela. Elle génère automatiquement un rapport par e-mail détaillant qui a effectué chaque modification et la raison de celle-ci.

En résumé, les LLMs peuvent automatiser des tâches fastidieuses effectuées par des employés. Cependant, deux objections évidentes se posent. Premièrement, les LLMs ne sont absolument pas nécessaires pour exécuter ce type de politique basée sur les rôles. Un simple langage de programmation et quelques instructions impératives suffiront. De plus, une infrastructure programmatique sera de toute façon nécessaire pour accéder aux données et envoyer l’e-mail. Dans ces contextes, les LLMs représentent assurément une complication d’ingénierie massive qui n’apporte aucun avantage tangible. En effet, les LLMs sont très lents et très coûteux; environ 10 ordres de grandeur de pire qu’une courte liste de règles. Ils sont un outil à utiliser en dernier recours, lorsque tout le reste a échoué. Ce n’est clairement pas le cas ici.

Deuxièmement, les tâches fastidieuses mentionnées ci-dessus sont tout à fait inutiles. L’entreprise devrait éliminer cette catégorie de tâches sans intérêt³. Les bureaucraties sont déjà suffisamment mauvaises, mais les technocraties sont pires. L’introduction de technologies trop complexes garantit que la bureaucratie s’enliserait encore davantage dans ses dysfonctionnements. Lokad, mon entreprise, s’attaque à ce genre de tâches fastidieuses depuis plus d’une décennie, et cela ne nécessite rien d’aussi compliqué et coûteux que les LLMs.

Ces contrats précisent les détails du prix payé par l’OEM, les exigences de qualité, les délais ainsi que les mesures de résilience que les fournisseurs doivent prendre pour garantir l’approvisionnement. Après avoir alimenté l’LLM avec les données de milliers de contrats, un OEM a pu identifier des réductions de prix auxquelles il avait droit pour avoir dépassé un certain seuil de volume.

Bien qu’il soit vrai que les entreprises échouent régulièrement à appliquer certaines clauses contractuelles avec leurs fournisseurs qui pourraient leur être bénéfiques, identifier les termes contractuels pertinents ne représente qu’une infime partie du défi — disons, 1 % ou peut-être beaucoup moins. De plus, cela peut être résolu avec un outil tel que ChatGPT, sans aucune préparation préalable. Il suffit de rédiger une requête et de soumettre sans cesse tous les PDF via l’interface utilisateur. Ce genre de détail relève d’un post LinkedIn intitulé “The 10 things I did with ChatGPT today” et non d’une publication Harvard-MIT.

Maintenant, le véritable défi est double : l’instrumentation et la relation. Du côté de l’instrumentation, les étapes administratives pour émettre des commandes et des paiements sont en grande partie automatisées dans la plupart des entreprises qui exploitent ce que l’on qualifie de “supply chain”. Ainsi, à moins de disposer d’une instrumentation de soutien étendue, traiter les cas marginaux va compliquer et retarder l’ensemble du processus.

De plus, du côté de la relation, si une clause contractuelle a été ignorée pendant des années, il serait naïf de penser que l’entreprise peut l’activer sans conséquence. Bien souvent, le fournisseur avait déjà intégré ce comportement laxiste du client dans ses tarifs, et se montrer pointilleux sur des termes contractuels marginaux se traduira en retour — ou possiblement par une augmentation de prix.

Plus généralement, les remises et les réductions de prix devraient être gérées dans le cadre des systèmes transactionnels classiques. Ce n’est pas de l’ingénierie spatiale, mais du bon vieux CRUD⁴. Encore une fois, introduire un LLM là où quelques règles impératives suffiraient est technologiquement insensé.

Un LLM permet aux planificateurs de poser des questions détaillées. Voici quelques exemples : “Quel serait le coût de transport supplémentaire si la demande globale de produits augmentait de 15 % ?” […] Voici comment un LLM peut répondre à ce type de questions de manière précise et efficace. De nombreuses tâches d’optimisation sont rédigées sous forme de programmes mathématiques […] Un LLM […] traduit une requête humaine en un code mathématique qui représente une petite modification du modèle mathématique original utilisé pour élaborer le plan.

C’est de l’utopie. À ce jour, le pourcentage d’entreprises disposant d’une “base de code monolithique unifiée” pour élaborer leurs décisions supply chain est pratiquement nul (nous en reparlerons ci-dessous). Au lieu de cela, les entreprises se retrouvent avec un océan de tableurs. Contrairement à la jolie image que se font les auteurs, il n’existe pas de “programmes mathématiques” avec lesquels interagir pour les LLMs. Bien que, conceptuellement, les LLMs puissent éditer et améliorer une pile enchevêtrée de tableurs à moitié obsolètes, tant que cela n’a pas été prouvé, il ne s’agit que de pure spéculation. Même les LLMs à la pointe de la technologie auraient du mal à éditer un seul grand tableur — la duplication passive de code que nécessitent les tableurs n’est pas du tout favorable aux LLMs — mais donner un sens à des centaines, voire des milliers, de feuilles reste pour l’instant de la pure science-fiction.

Maintenant, il existe en effet quelques entreprises qui bénéficient d’une base de code monolithique unifiée pour gérer les processus de prise de décision en supply chain — à savoir les clients de Lokad. Si les auteurs avaient, comme nous, une réelle expérience dans le domaine, ils sauraient que ces bases de code sont considérables ; typiquement des dizaines de milliers de lignes de code, malgré le fait que nous utilisions un DSL (langage spécifique au domaine)⁵ dédié à la supply chain. Ce DSL est, soit dit en passant, environ 10 fois plus concis que Python ou Java pour ce type de tâche. Malheureusement, il n’existe aucun raccourci : pour toute décision d’intérêt, il y a des dizaines de tableaux, couvrant des centaines de champs, impliqués dans le calcul. Bien qu’il soit concevable que de nouvelles améliorations de notre DSL puissent réduire davantage le nombre de lignes de code, ces bases de code ne seront jamais petites.

Encore une fois, les LLMs pourraient, conceptuellement, éditer et améliorer une base de code complexe tout en étant dirigés par un contributeur non technique. Cependant, nous sommes à nouveau dans le domaine de la science-fiction. Il a déjà été prouvé que les LLMs sont d’excellents outils de productivité pour les programmeurs compétents. En d’autres termes, si vous savez déjà programmer, les LLMs peuvent vous aider à programmer plus rapidement. Pourtant, ce n’est pas ce que les auteurs de l’article avancent. Leur proposition est précisément que les LLMs pourraient être utilisés pour permettre à des contributeurs non techniques d’apporter des contributions techniques. D’après l’état actuel de l’art des LLMs, cette proposition est invariablement fausse, sauf dans le cadre de petits environnements de test qui ne reflètent pas la complexité ambiante massive des supply chains réelles.

Les planificateurs peuvent utiliser la technologie des LLMs pour mettre à jour les modèles mathématiques de la structure d’une supply chain et des exigences commerciales afin de refléter l’environnement économique actuel. De plus, un LLM peut informer les planificateurs d’un changement des conditions commerciales.

Les auteurs misent tout sur la science-fiction. Cette affirmation est techniquement indiscernable de “un LLM peut émettre des correctifs à un dépôt de code sur GitHub à partir de tickets soumis par des utilisateurs non techniques”. Ce serait une nouvelle fantastique si cela était possible, mais encore une fois, les LLMs actuels sont loin de pouvoir accomplir ce genre d’exploit de manière fiable pour des demandes sérieuses. Lors de la présentation de cas d’utilisation pour une technologie nouvelle, il est essentiel de transmettre précisément les limites de cette technologie. Les quatre coauteurs semblent complètement ignorants de l’état actuel de l’art des LLMs; cela dit, j’ai le pressentiment qu’ils ne le sont pas. Au lieu de cela, nous entendons du discours publicitaire insipide de la part de personnes qui savent pertinemment ce qu’elles font — ce qui est sans doute bien pire.

Le besoin de modifier le plan de supply chain pourrait également être entraîné par une technologie basée sur les LLMs. Par exemple, après avoir analysé les données d’expédition d’un fournisseur spécifique, elle pourrait générer une alerte indiquant que le délai d’approvisionnement du fournisseur a considérablement augmenté au cours des derniers mois.

Détecter si un délai d’approvisionnement est anormal n’est absolument pas le domaine d’action d’un LLM. Un LLM peut, cependant, être sollicité pour écrire un bout de code afin d’effectuer cette analyse. Nous revoilà face au post LinkedIn “Top 10 things I did with ChatGPT today”. Pourquoi s’arrêter là et ne pas mettre à jour directement la logique de commande là où l’information sur le délai est consommée ? C’est exactement ce que suggèrent les auteurs plus tard dans l’article.

Nous envisageons que, dans les prochaines années, la technologie basée sur les LLMs soutiendra des scénarios de prise de décision de bout en bout.

Si par soutenir, les auteurs entendaient rendre les programmeurs plus productifs — ces derniers étant chargés de coder la prise de décision de bout en bout — alors c’est déjà possible — en fait, c’est quelque chose que Lokad pratique depuis un certain temps. Toutefois, si l’on retire les programmeurs humains de l’équation, cette déclaration se rapproche davantage de “nous envisageons qu’ici quelques années, les technologies basées sur les LLMs atteindront l’AGI (intelligence artificielle générale)”.

Les auteurs, surfant sur le mot à la mode “Gen AI”, sont entièrement négateurs du fait que les LLMs puissent avoir, eux aussi, leurs propres limites. Voici ce que les auteurs avancent dans leur section de conclusion “Overcoming Barriers”:

Adoption et formation. Utiliser un LLM pour optimiser les supply chains nécessite un langage très précis […] Chaque interprétation conduit à des décisions différentes.

Non, c’est tout simplement faux — à moins que “langage très précis” ne soit interprété comme “langage de programmation” (ce qui est effectivement très précis). Pour optimiser une supply chain à l’aide d’un LLM, il faut un ingénieur humain capable de coder entièrement seul, certes plus lentement. Dans un avenir prévisible, aucune quantité de formation, hormis l’acquisition d’une compétence en programmation, ne permettra aux utilisateurs de réaliser des optimisations de supply chain avec le soutien des LLMs.

Dire au PDG ou au directeur supply chain qu’il lui suffit de former son équipe à utiliser un “langage précis” est complètement trompeur. Le genre d’ateliers de formation qui découleraient de cette vision est assuré d’être une perte totale de temps pour toutes les parties impliquées.

Vérification. La technologie des LLMs peut occasionnellement produire une sortie incorrecte. Ainsi, un défi général consiste à maintenir la technologie “sur les rails” — c’est-à-dire, identifier les erreurs et y remédier.

Bien que les LLMs soient probabilistes par conception, ce problème est éclipsé par l"incertitude sémantique qui imprègne les systèmes de supply chain. En d’autres termes, il est fort probable qu’un LLM vous donne la bonne réponse au mauvais problème. L’expérience de Lokad indique que, fréquemment, la seule manière de vérifier si une implémentation donnée (pilotant une décision de supply chain) est correcte est d’effectuer un test expérimental restreint⁶. Le retour d’information du monde réel n’est pas une option. Le savoir ne peut être invoqué de nulle part — même les LLMs de niveau AGI seraient confrontés à cet obstacle.

Ici, les auteurs se contentent de remplir les blancs. Ils font une affirmation correcte — mais triviale — sur la nature des LLMs sans même tenter de vérifier si le problème est central ou non. Si les auteurs avaient réellement géré des supply chains réelles à l’aide des LLMs, ils se seraient rendu compte, comme nous, que cette préoccupation n’est qu’un petit problème au sein d’une longue liste de problèmes bien plus importants — et bien plus impactants.

Pour conclure, la loi de Brandolini s’applique ici : La quantité d’énergie nécessaire pour réfuter du bulls**t est d’un ordre de grandeur supérieure à celle requise pour le produire. Cet article est tellement mauvais qu’il pourrait avoir été écrit par ChatGPT — et peut-être l’a-t-il été, pour autant que je sache. D’après mes observations superficielles, des dizaines d’articles tout aussi mauvais sont produits chaque jour sur Gen-AI et SCM. La notoriété des auteurs m’a motivé à préparer cette revue. En y regardant de plus près, ce ne serait pas la première fois qu’un fournisseur promet de révolutionner un domaine tout en n’offrant rien de substantiel. Pourtant, le même fournisseur le faisant deux fois⁷ deux années de suite dans le même domaine pourrait être excessif. Cependant, le milieu académique devrait au moins tenter d’exercer une pensée critique au lieu de sauter joyeusement dans le train en marche des mots à la mode.