Une critique de "Comment l'IA générative améliore la gestion de la supply chain"

Joannes Vermorel

La Harvard Business Review, dans le cadre de son numéro de janvier-février 2025, a récemment publié Comment l’IA générative améliore la gestion de la supply chain¹ par Ishai Menache (Microsoft), Jeevan Pathuri (Microsoft), David Simchi-Levi (Professeur, MIT) et Tom Linton (McKinsey). Comme le suggère le titre, l’article fournit une série d’exemples censés illustrer comment les LLM (large language models) peuvent contribuer à la gestion de la supply chain. Étant donné la liste des organisations d’élite (Microsoft, McKinsey, MIT et même Harvard) impliquées dans la publication de cet article, on s’attendrait à des points de vue profonds et éclairants, de ceux qui articulent soigneusement comment une brillante technologie - les LLM - va contribuer à l’amélioration des chaînes d’approvisionnement.

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. La prémisse même de l’article peut être résumée ainsi : les LLM 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. L’approche gadgetoïde consiste, lors de la découverte d’une nouvelle technologie, à fixer rapidement cette technologie sur un système existant. Cela se fait généralement sans tenir compte des limitations de la technologie ou des changements qui seraient apportés au système. En conséquence, cette approche produit invariablement des gadgets - des outils amusants d’un 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 les clients potentiels dans des directions qui sont garanties d’être une perte de temps et d’argent.

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

Clarifions immédiatement que bien que je convienne que les LLM peuvent être utilisés pour l’amélioration des chaînes d’approvisionnement, les LLM peuvent également être une distraction totale - selon la manière dont l’entreprise est abordée. Ce point se trouve être exactement le problème fondamental qui afflige l’article en question. Un article étroitement lié de Microsoft² souffre également de ce problème ; bien que, pour des raisons de clarté, ma critique restera axée sur l’article de Harvard.

Avant d’aborder l’absurdité technologique fondamentale, soulignons 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 faire la publicité de ses services de la manière qu’il juge appropriée, mais impliquer à la fois Harvard (via la publication) et le MIT (via la co-rédaction) dans une pièce promotionnelle me dérange. À tout le moins, l’article devrait souligner que les coauteurs ont des conflits d’intérêts évidents. Le monde universitaire ne devrait pas cautionner une activité promotionnelle dissimulée des fournisseurs de technologies, quelle que soit leur taille et leur influence.

Avertissement : Le lecteur perspicace aura réalisé que j’ai également un conflit d’intérêts. Oui, je dirige une entreprise de logiciels de gestion de la supply chain et, par conséquent, j’ai un intérêt personnel à contredire les absurdités que Microsoft, McKinsey, le MIT et Harvard propagent. Mes cartes sont maintenant sur la table.

Passons maintenant à l’examen des affirmations faites dans l’article.

Les planificateurs surveillent également les changements dans le plan de demande, appelé la dérive de la demande, sur une base mensuelle pour s’assurer que le plan révisé répond à toutes les exigences des clients et respecte les directives budgétaires […] La technologie basée sur LLM fait maintenant tout cela. Elle génère automatiquement un rapport par e-mail qui détaille qui a apporté chaque modification et la raison de celle-ci.

En bref, les LLM peuvent automatiser les tâches fastidieuses des employés. Cependant, il y a deux objections évidentes. Premièrement, les LLM sont totalement inutiles pour exécuter ce type de politique basée sur les rôles. Un langage de programmation simple et quelques instructions impératives suffiront. De plus, la plomberie programmatique sera nécessaire de toute façon pour accéder aux données et envoyer l’e-mail. Dans ces paramètres, les LLM représentent une complication d’ingénierie massive qui ne fournit aucun avantage tangible. En effet, les LLM sont très lents et très coûteux ; environ 10 ordres de grandeur pires qu’une courte liste de règles. Ce sont des outils à 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 totalement inutiles. L’entreprise devrait éliminer cette catégorie de tâches inutiles[^bureaucraties]. Les bureaucraties sont déjà assez mauvaises, mais les technocraties sont pires. Introduire des technologies compliquées et coûteuses à la fête garantit que la bureaucratie sera encore plus enracinée dans ses méthodes dysfonctionnelles. Lokad, ma société, a éliminé 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 LLM.

Ces contrats spécifient les détails du prix payé par le fabricant d’équipement d’origine (OEM), les exigences de qualité, les délais de livraison et les mesures de résilience que les fournisseurs doivent prendre pour garantir l’approvisionnement. Après avoir alimenté les LLM avec des données provenant 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 leur seraient 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 comme ChatGPT sans aucune préparation. Il suffit de composer une requête et de soumettre à plusieurs reprises tous les PDF via l’interface utilisateur. Ce genre de trivialité appartient à un article LinkedIn intitulé “Les 10 choses que j’ai faites avec ChatGPT aujourd’hui” et non à 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 largement automatisées dans la plupart des entreprises qui exploitent quelque chose qui qualifie comme une “supply chain”. Ainsi, à moins qu’il n’y ait une instrumentation de soutien étendue, traiter les cas marginaux va compliquer et retarder tout.

De plus, du côté de la relation, si une clause contractuelle a été ignorée pendant des années, il est naïf de penser que l’entreprise peut activer la clause sans aucune conséquence. Le plus souvent, le fournisseur a déjà intégré ce comportement laxiste du client dans ses prix, et chipoter sur des termes contractuels marginaux sera répondu de la même manière, voire éventuellement par une augmentation des prix.

Plus généralement, les remises et les réductions de prix doivent être gérées dans le cadre des systèmes commerciaux transactionnels habituels. Ce n’est pas de l’ingénierie spatiale, mais simplement du CRUD³. Une fois de plus, apporter un LLM là où quelques règles impératives suffiraient est technologiquement absurde.

Un LLM permet aux planificateurs de poser des questions détaillées. Voici quelques exemples : “Quel serait le coût supplémentaire de transport si la demande globale de produits augmentait de 15% ?” […] Voici comment un LLM peut répondre avec précision et efficacité à des questions de ce type. De nombreuses tâches d’optimisation sont formulées sous la forme de programmes mathématiques […] Un LLM […] traduit une requête humaine en un code mathématique qui est un petit changement par rapport au modèle mathématique original utilisé pour produire le plan.

C’est une pensée utopique. À ce jour, le pourcentage d’entreprises bénéficiant d’une “base de code monolithique unifiée” pour dériver leurs décisions en matière de supply chain est virtuellement nul (plus de détails ci-dessous). Au lieu de cela, les entreprises ont un océan de feuilles de calcul. Contrairement à l’image idyllique que les auteurs dépeignent, il n’y a pas de “programmes mathématiques” avec lesquels interagir pour les LLM. Bien que les LLM puissent, conceptuellement, modifier et améliorer un tas de feuilles de calcul désordonnées et semi-obsolètes, jusqu’à preuve du contraire, il s’agit de pure spéculation. Même les LLM de pointe auraient du mal à modifier une seule grande feuille de calcul - la duplication passive de code que les feuilles de calcul impliquent n’est pas du tout favorable aux LLM - mais donner un sens à des centaines, voire des milliers, de feuilles reste de la pure science-fiction à ce stade.

Maintenant, il est vrai qu’il y a 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 matière de supply chain - à savoir les clients de Lokad. Si les auteurs avaient, comme nous, réellement de l’expérience en la matière, ils auraient su que ces bases de code sont importantes ; typiquement des dizaines de milliers de lignes de code, malgré le fait que nous utilisons un DSL (domain-specific language)⁴ dédié à la supply chain. Ce DSL est environ 10 fois plus concis que Python ou Java pour ce type de tâche, soit dit en passant. Il n’y a malheureusement pas de raccourci : pour toute décision d’intérêt, des dizaines de tables, couvrant des centaines de champs, sont impliquées dans le calcul. Bien qu’il soit concevable que des améliorations ultérieures 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 LLM pourraient, conceptuellement, modifier 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. Les LLM sont déjà reconnus comme des outils de productivité fantastiques pour les programmeurs compétents. En d’autres termes, si vous savez déjà programmer, les LLM peuvent vous aider à programmer plus rapidement. Pourtant, ce n’est pas ce que disent les auteurs de l’article. Leur proposition est précisément que les LLM peuvent être utilisés pour permettre aux contributeurs non techniques d’effectuer des contributions techniques. Sur la base de l’état actuel de l’art des LLM, cette proposition est invariablement fausse, sauf dans le cadre de petits environnements de test qui ne reflètent pas la complexité ambiante massive des chaînes d’approvisionnement du monde réel.

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

Les auteurs insistent sur la science-fiction. Cette affirmation est techniquement indiscernable de “un LLM peut apporter des correctifs à un référentiel de code sur GitHub en se basant sur des tickets soumis par des utilisateurs non techniques”. Ce serait une excellente nouvelle si cela était possible, mais encore une fois, les LLM actuels sont loin d’être capables d’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 nouvelle technologie, il est essentiel de transmettre avec précision les limites de ladite technologie. Les quatre coauteurs semblent être totalement inconscients de l’état actuel de l’art des LLM ; cela dit, j’ai le sentiment qu’ils ne le sont pas. Au lieu de cela, nous obtenons des discours publicitaires de personnes qui sont parfaitement conscientes de ce qu’elles font, ce qui est sans doute bien pire.

Le besoin de modifier le plan d’approvisionnement peut également être motivé par la technologie basée sur les LLM. Par exemple, après avoir analysé les données d’expédition d’un fournisseur spécifique, il peut générer une alarme indiquant que le délai de livraison du fournisseur a considérablement augmenté au cours des derniers mois.

Détecter si un délai de livraison est anormal n’est absolument pas ce qu’un LLM peut faire. Un LLM peut cependant être incité à écrire un morceau de code pour effectuer cette analyse. Nous en revenons au post LinkedIn “Les 10 choses que j’ai faites avec ChatGPT aujourd’hui”. Pourquoi s’arrêter là et ne pas mettre à jour directement la logique de commande là où les informations sur les délais de livraison sont utilisées ? C’est exactement ce que les auteurs suggèrent plus tard dans l’article.

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

Si par “soutien”, les auteurs voulaient dire “rendre les programmeurs plus productifs” - ces programmeurs étant chargés de coder la prise de décision de bout en bout - alors cela est déjà possible - en fait, c’est quelque chose que Lokad fait depuis un certain temps. Cependant, si nous retirons les programmeurs humains de l’équation, cette déclaration devient quelque chose de plus proche de “nous envisageons que dans les prochaines années, les technologies basées sur les LLM atteindront une intelligence artificielle générale (AGI)”.

Les auteurs, surfant sur le buzzword “Gen AI”, ignorent totalement que les LLM pourraient avoir leurs propres limitations. Voici ce que les auteurs avancent dans leur section de conclusion “Surmonter les obstacles” :

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

Non, c’est complètement faux - à moins que “langage très précis” ne soit compris comme “langage de programmation” (car ceux-ci sont effectivement très précis). Pour optimiser une chaîne d’approvisionnement à l’aide d’un LLM, vous avez besoin d’un ingénieur humain capable de faire la programmation entièrement par lui-même, bien que plus lentement. Pour un avenir prévisible, aucune formation, sauf celle de devenir compétent en programmation, ne permettra aux utilisateurs d’effectuer des optimisations de chaîne d’approvisionnement avec le soutien des LLM.

Dire au PDG ou au directeur de la chaîne d’approvisionnement qu’il lui suffit de former son équipe à utiliser un “langage précis” est totalement trompeur. Les ateliers de formation qui résulteraient de cette vision sont garantis d’être une perte de temps totale pour toutes les parties impliquées.

Vérification. La technologie LLM peut parfois produire une sortie incorrecte. Ainsi, un défi général consiste à maintenir la technologie “dans les rails”, c’est-à-dire à identifier les erreurs et à s’en remettre.

Bien que les LLM soient probabilistes par conception, ce problème est éclipsé par l’incertitude sémantique qui imprègne les systèmes de chaîne d’approvisionnement. En d’autres termes, le LLM est très susceptible de vous donner la bonne réponse au mauvais problème. L’expérience de Lokad indique que souvent, la seule façon de vérifier si une implémentation donnée (qui conduit à une décision de chaîne d’approvisionnement) est correcte est de réaliser un test expérimental limité⁵. Les retours du monde réel ne sont pas une option. La connaissance ne peut pas être conjurée à partir de rien - même les LLM de niveau AGI seraient encore confrontés à cet obstacle.

Ici, les auteurs se contentent de remplir. Ils font une déclaration correcte mais triviale sur la nature des LLM sans même essayer de voir si le problème est une préoccupation centrale ou non. Si les auteurs avaient réellement géré des chaînes d’approvisionnement réelles à l’aide de LLM, ils auraient réalisé, comme nous, que cette préoccupation est un petit problème parmi une longue liste de problèmes beaucoup plus importants et beaucoup plus impactants.

Pour conclure, la loi de Brandolini s’applique ici : La quantité d’énergie nécessaire pour réfuter des bêtises est un ordre de grandeur plus élevé que celle nécessaire pour les produire. Cet article est tellement mauvais qu’il aurait pu être écrit par ChatGPT - et peut-être l’a-t-il été, pour tout ce que je sais. D’après mes observations occasionnelles, des dizaines d’articles tout aussi mauvais sont produits chaque jour sur Gen-AI et SCM. La notoriété des auteurs m’a motivé à rédiger cette critique. En prenant du recul, ce ne serait pas la première fois qu’un fournisseur promet de révolutionner un domaine sans avoir rien de concret à offrir. Pourtant, le même fournisseur le fait deux fois⁶ deux années de suite dans le même domaine, ce qui pourrait être excessif. Encore une fois, le monde universitaire devrait au moins essayer de faire preuve de pensée critique au lieu de sauter joyeusement dans le train des buzzwords.