Discuter avec votre Supply Chain ne la réparera pas
Tous les quelques jours, une nouvelle démo fait le tour : vous tapez une question en anglais simple — « Que se passerait-il si la demande montait en flèche en Allemagne ? », « Que se passerait-il si nous fermions cette usine ? », « Que se passerait-il si nous changions de fournisseurs ? » — et un assistant répond avec assurance par un plan révisé, une brève explication et une liste ordonnée des actions suivantes. L’argument est irrésistible : la supply chain, enfin rendue conversationnelle. La planification, enfin rendue sans friction. L’optimisation, enfin rendue accessible.
Dans mon livre Introduction to Supply Chain (voir le Chapitre 6, notamment les parties traitant de « l’intelligence générale » et de l’héritage de l’OR), j’ai soutenu que la supply chain est une discipline qui confond, à de nombreuses reprises, des interfaces élégantes avec le progrès. Cet argument prend de l’importance aujourd’hui, car les grands modèles de langage (LLM) sont présentés — par des chercheurs sérieux et par des fournisseurs sérieux — comme la pièce manquante qui reliera enfin les mathématiques aux opérations, et la planification à la réalité.
Ce que la communauté construit réellement
La communauté de la recherche opérationnelle a fait preuve d’une remarquable cohérence quant à ce qu’elle attend des LLM : un traducteur universel entre l’intention humaine et la machinerie mathématique.
La série de compétitions NL4Opt lors de NeurIPS est explicite sur l’objectif : accroître « l’accessibilité et l’utilisabilité des solveurs d’optimisation » en permettant aux non-experts d’exprimer des problèmes en langage naturel, puis en générant les artefacts de modélisation (y compris le code de modélisation LP et MIP) que les solveurs peuvent exploiter. Ce n’est pas une idée marginale ; elle est en train d’être formalisée en tâches de référence, ensembles de données, métriques d’évaluation et structures de compétitions à primes.
OptLLM pousse la même idée du côté de la recherche vers un flux de travail de bout en bout : l’utilisateur énonce un problème d’optimisation en langage naturel ; le système le convertit en formulations mathématiques et en code de programmation ; puis il appelle un solveur externe et itère à travers un dialogue en plusieurs rounds pour affiner le modèle. En d’autres termes : anglais → mathématiques → code → solveur → résultats → anglais, avec le LLM orchestrant la boucle.
Le chapitre TutORials 2024 d’INFORMS par Wasserkrug, Boussioux et Sun propose une approche plus large, orientée vers les professionnels : les LLM peuvent accélérer la création et le déploiement de solutions OR/MS en (i) réduisant le temps de développement tout en améliorant la qualité des solutions, (ii) en extrayant des données structurées à partir d’un texte non structuré sans avoir à construire des modèles NLP sur mesure (ils mentionnent explicitement la prévision de la demande comme cas d’usage motivant), et (iii) en permettant des interfaces en langage naturel afin que les utilisateurs professionnels puissent interagir de manière flexible avec les modèles analytiques. Ce chapitre se distingue non seulement par son optimisme, mais aussi par son insistance sur l’utilisation responsable : les LLM sont présentés comme des outils puissants, mais des outils nécessitant une gouvernance et une responsabilité.
Par ailleurs, la recherche sur l’apprentissage de l’optimisation intègre également les LLM — pas seulement en tant qu’« interfaces », mais aussi en tant que composants dans l’écosystème des solveurs lui-même. L’ambition du « modèle de fondation » est arrivée en MILP : des chercheurs de Microsoft proposent d’entraîner un modèle unique à travers diverses classes de MILP et introduisent MILP‑Evolve, un cadre évolutionnaire basé sur les LLM qui génère de grandes classes de problèmes MILP diversifiées « avec une quantité illimitée d’instances », soutenant des tâches telles que l’apprentissage du branchage et l’alignement des instances MILP avec des descriptions en langage naturel. Une étude de 2025 sur les LLM pour l’optimisation évolutionnaire va plus loin et catégorise les paradigmes émergents : les LLM en tant qu’optimiseurs autonomes, les LLM intégrés dans les algorithmes d’optimisation, et les LLM utilisés à un niveau supérieur pour la sélection et la génération d’algorithmes — pointant explicitement vers des « écosystèmes agentiques auto-évolutifs » pour l’optimisation.
Du côté de la planification de la supply chain, les propositions riment presque parfaitement avec l’agenda de l’OR — mais avec un point focal différent : pas « rendre les solveurs accessibles », mais « rendre les planificateurs rapides ».
L’article 2025 de MIT Sloan Executive Education sur les LLM dans la planification de la supply chain est représentatif. Il décrit des planificateurs posant des questions complexes du type « et si » en langage naturel ; le LLM traduit la requête en ajustements mathématiques et renvoie des informations compréhensibles par l’humain. Il affirme que ce qui nécessitait auparavant des « jours » d’échanges avec des ingénieurs peut devenir des « minutes », et il étend la promesse aux perturbations en « temps réel » : les planificateurs peuvent « ajuster dynamiquement les modèles mathématiques » sans faire appel aux équipes informatiques, et relancer l’optimisation pour produire des plans révisés expliqués en langage clair. Le même article admet, presque en aparté, la difficulté centrale : la validation — s’assurer que les ajustements générés par l’IA correspondent aux conditions réelles de l’entreprise — demeure un défi.
Simchi-Levi, Mellou, Menache et Pathuri (2025) rendent explicite la thèse de la « démocratisation » : les planificateurs et les dirigeants passent actuellement trop de temps à comprendre les résultats, à exécuter des scénarios et à mettre à jour les modèles, de sorte que les LLM peuvent « démocratiser la technologie de la supply chain » en facilitant la compréhension et l’interaction « sans l’intervention humaine », réduisant le temps de décision de « jours et semaines » à « minutes et heures ».
Le projet OptiGuide de Microsoft Research se situe exactement à cette intersection de l’OR et de la planification : il vise à « démocratiser la prise de décision » en combinant optimisation et generative AI, et il revendique une utilisation en production pour les planificateurs de supply chain cloud répondant aux questions « et si » et recevant des recommandations actionnables.
Les fournisseurs de logiciels, sans surprise, se sont concentrés sur les mêmes thématiques : copilots, agents, requêtes en langage naturel et décisions plus rapides.
SAP positionne Joule comme un copilot en generative AI intégré à ses applications d’entreprise, y compris la supply chain, et les pages spécifiques IBP de SAP mettent en avant un accès conversationnel à la documentation produit (une manière plus fluide de rechercher et d’obtenir des conseils) ainsi que l’intégration de Joule avec SAP IBP. Les notes de version communautaires de SAP pour IBP mentionnent l’intégration de Joule comme une innovation dans cette ligne de version.
Les annonces d’Oracle de 2025 mettent en avant des « agents AI » intégrés dans Oracle Fusion Cloud Applications. Pour la supply chain, Oracle affirme que ces agents automatisent les processus, optimisent la planification et l’exécution, et accélèrent la prise de décision ; il énumère même des agents tels qu’un conseiller en planification pour exceptions et notes qui résume les alertes et les annotations. La documentation sur la préparation d’Oracle décrit également un agent « Supply Chain Planning Process Advisor » construit avec des LLM + RAG pour répondre aux questions des planificateurs concernant les responsabilités, les tâches quotidiennes et les processus d’escalade, en se basant sur les documents d’entreprise que le client télécharge.
Le communiqué de presse ICON 2025 de Blue Yonder présente des « agents AI » et un « graphe de connaissances de la supply chain », affirmant que ces agents permettent aux entreprises de « voir, analyser, décider et agir » avec la rapidité d’une machine et que l’agentic AI est imprégné dans la planification et l’exécution.
Kinaxis décrit des capacités d’AI agentique et generative qui abaissent les barrières à l’interaction avec les données de la supply chain — interroger un « jumeau numérique » en langage naturel et recevoir des réponses — et ses documents publics ainsi que la couverture des analystes indépendants décrivent un cadre multi-agent destiné à réduire la dépendance à l’IT et à permettre aux planificateurs d’interagir directement avec les données opérationnelles.
o9 pousse le même discours sous un autre nom : des « agents GenAI » associés à un graphe de connaissances d’entreprise évoluant vers un « large knowledge model », positionné comme une avancée majeure en productivité et en expertise pour les fonctions de planification.
Par-dessus tout cela se trouve Gartner, qui fournit le langage de catégorie. Dans un communiqué de presse d’août 2025, Gartner prédit une prolifération rapide des assistants AI et des agents AI spécifiques à des tâches dans les applications d’entreprise, décrit les « étapes » de l’évolution de l’agentic AI, et avertit qu’une idée reçue courante consiste à appeler les assistants des « agents » — une méprise qu’il qualifie de « agentwashing ».
Alors, oui : un travail réel est en cours. Des benchmarks, des cadres de référence, des architectures d’agents, des intégrations et une multitude d’ingénierie orientée production. La question n’est pas de savoir si les LLM peuvent être intégrés aux outils de la supply chain — ils le sont déjà. La question est de savoir si cette intégration répond aux véritables raisons pour lesquelles la prise de décision en supply chain reste obstinément médiocre.
Pourquoi je ne suis pas convaincu que l’interface soit le goulot d’étranglement
La communauté de l’OR a raison sur un point : l’optimisation est difficile à exprimer de manière claire. La communauté de la planification a également raison sur un point : les gens perdent du temps à traduire des questions en feuilles de calcul, en courriels, en réunions, en tickets et en modifications ad hoc des modèles. Un LLM peut réduire cette friction. Il peut raccourcir le chemin entre « je me demande… » et « voici une réponse calculée », tout comme le décrit l’article de MIT Sloan.
Mais les supply chain ne connaissent pas l’échec parce que les planificateurs manquent d’un moyen plus rapide de poser des questions.
Des décennies de solveurs, de langages de modélisation et de progrès académiques existent déjà. L’affirmation intégrée dans NL4Opt — « rendre les solveurs utilisables par des non-experts via le langage naturel » — présuppose que le principal obstacle est l’incapacité de l’utilisateur à formuler des problèmes. C’est une histoire rassurante pour les chercheurs, car elle transforme un échec organisationnel chaotique en un problème de traduction. Il se trouve également que cela est en grande partie faux en supply chain.
Ce qui bloque l’adoption dans le monde réel, ce n’est pas que les gens ne puissent pas taper des contraintes. C’est que les contraintes, les objectifs et la sémantique des données sont systématiquement erronés — ou, plus précisément, ils le sont de manière économiquement significative. Vous pouvez générer des montagnes de code de modélisation et continuer à optimiser des absurdités.
Ce n’est pas une nouvelle critique. Russell Ackoff a soutenu en 1979 que l’OR était devenue « contextuellement naïve » et que son application était de plus en plus limitée à des problèmes relativement insensibles à leur environnement. Les supply chain sont tout le contraire de l’insensibilité à l’environnement. Elles sont dominées par la volatilité, les effets de substitution, des données manquantes, des retours d’information retardés et des incitations qui modifient le comportement dès que vous commencez à « optimiser ».
L’agenda des LLM en OR a tendance à sous-estimer une asymétrie brutale : écrire un modèle est plus facile que de le valider. OptLLM peut générer des formulations et du code, puis itérer dans le dialogue. Pourtant, la véritable difficulté n’est pas de produire un autre objet mathématique — c’est de s’assurer que cet objet correspond aux véritables compromis économiques de l’entreprise, aux contraintes opérationnelles et à la réalité des mesures. Un LLM peut produire une contrainte plausible ; il ne peut pas certifier que cette contrainte reflète ce que vit réellement votre entrepôt à 3 heures du matin lors d’une promotion, avec le véritable planning de la main-d’œuvre, les vraies politiques d’emballage, les vraies règles de réapprovisionnement et les vrais modes de défaillance.
En planification, cette même asymétrie devient encore plus dangereuse, car le réflexe culturel est de faire confiance au plan. L’article de MIT Sloan se félicite que les planificateurs puissent « ajuster dynamiquement les modèles mathématiques » sans l’IT. Simchi-Levi et ses co-auteurs le présentent comme supprimant la nécessité d’avoir des équipes de data science et des fournisseurs de technologie dans la boucle. Cela est vendu comme un moyen d’autonomisation. Pour moi, c’est contourner la friction même qui empêchait auparavant la dérive incontrôlée des modèles.
Si changer le modèle est facile, l’organisation changera le modèle constamment. Non pas parce que c’est judicieux, mais parce que cela procure une satisfaction psychologique. Chaque perturbation invite à une nouvelle exception. Chaque question d’un dirigeant suscite un nouveau scénario. Chaque réunion appelle à une nouvelle modification pour satisfaire l’intuition de quelqu’un. Vous obtenez un mouvement plus rapide, oui — mais vous obtenez aussi une entropie plus rapide.
Il est compréhensible que les fournisseurs se soient orientés vers des « agents » qui résument, expliquent et guident. Le Planning Process Advisor d’Oracle est essentiellement une couche LLM+RAG superposée aux politiques et procédures : il répond aux questions à partir des documents que vous téléchargez et intègre cette expérience de chat dans les pages de workflow. Le positionnement de Joule dans IBP par SAP met en avant, de manière similaire, la recherche conversationnelle et les réponses basées sur la documentation. Ce sont des fonctionnalités de productivité légitimes. Elles peuvent réduire le temps perdu à chercher le bon document de processus. Mais elles ne changent pas de manière significative la qualité des décisions. Elles sont, au mieux, un meilleur système d’aide.
Ensuite, nous arrivons à la grande histoire de l’« agentic ». Blue Yonder annonce plusieurs agents AI, imprégnés dans la planification et l’exécution, visant une optimisation continue et une prise de décision à la vitesse de la machine. Kinaxis décrit des cadres agentiques, des agents AI qui surveillent et agissent en temps réel, et une interaction en langage naturel avec un jumeau numérique. Gartner prédit un monde rempli de ces éléments, tout en avertissant qu’une grande partie de ce qui est vendu comme des agents est en réalité des assistants — « agentwashing ».
L’ironie est que l’avertissement de Gartner n’est pas une simple remarque annexe ; c’est le fait central. La plupart de ces « agents » ne sont que des enveloppes. Ils se placent au-dessus des workflows existants, automatisent des fragments d’interaction et rendent l’interface plus agréable. Ils ne réparent pas la logique économique des décisions, ni ne résolvent les problèmes fondamentaux de fidélité des données, d’incertitude et d’incitations. Ils peuvent réduire le délai de prise de décision dans le sens étroit où quelqu’un peut cliquer plus rapidement — mais pas dans le sens profond où l’entreprise commet moins d’erreurs.
Même les intégrations académiques plus substantielles — LLM + optimisation de réseau, avec tableaux de bord et explications tenant compte des rôles — encadrent la difficulté principale comme étant le « pont » entre les résultats de l’OR et la compréhension des parties prenantes, en traduisant les résultats en langage naturel et en indicateurs clés de performance contextuels. Encore une fois : c’est utile. Mais cela maintient l’hypothèse selon laquelle le modèle est correct ; il suffit que les gens le comprennent. En supply chain, le modèle est souvent le problème.
Donc, lorsque j’entends « les LLM démocratiseront l’optimisation », je traduis cela par : « nous allons démocratiser la production de pseudo-modèles. » Lorsque j’entends « les LLM permettront aux planificateurs de mettre à jour les modèles sans l’IT », je traduis cela par : « nous allons accélérer le rythme auquel des modèles fragiles sont corrigés, non corrigés et recorrigés. » Et lorsque j’entends « l’agentic AI orchestrera des workflows de bout en bout », je demande : orchestrer vers quel objectif, sur quelle sémantique, et avec quelle responsabilité ?
Où les LLM peuvent être véritablement utiles
Tout cela n’est pas un argument pour ignorer les LLM. C’est un argument pour arrêter de prétendre que la conversation est un substitut à la compétence.
Le chapitre OR/MS TutORials a raison de souligner que les LLM peuvent accélérer la production d’applications de prise de décision, aider à transformer un texte non structuré en signaux structurés et fournir des couches d’interaction en langage naturel — tout en insistant sur une utilisation responsable. C’est exactement là que les LLM excellent : pas en tant que moteur de décision, mais en tant que multiplicateur de productivité pour les ingénieurs et analystes qui construisent le véritable moteur de décision.
Si vous utilisez des LLMs pour écrire du code d’assemblage plus rapidement, pour générer des tests, pour rédiger de la documentation, pour extraire des règles métier désordonnées des contrats et des SOPs en représentations structurées, vous améliorez la partie du pipeline qui constitue en réalité un goulot d’étranglement : l’ingénierie lente, coûteuse et sujette aux défaillances des données et de la logique. Si vous utilisez des LLMs pour aider les auditeurs, les cadres et les opérateurs à comprendre pourquoi une décision calculée a été prise—en produisant des explications fondées sur des preuves traçables—vous pouvez améliorer l’adoption sans renoncer au contrôle.
Même la notion de “démocratisation” peut être reformulée de manière productive. L’affirmation d’OptiGuide selon laquelle il a été utilisé en production pour des planificateurs de supply chain cloud répondant à des questions du type “et si ?” n’est pas triviale. Mais la valeur ne réside pas dans le fait qu’un planificateur puisse discuter avec un optimiseur. La valeur réside dans le fait qu’une entreprise dotée d’une solide base d’optimisation puisse construire une interface plus sûre et plus utilisable—une interface qui expose les bons leviers et explications, plutôt que de laisser n’importe qui réécrire à la légère les mathématiques sous-jacentes.
Et oui, l’agenda de l’apprentissage par le solveur—les foundation models pour MILP, le learned branching, etc.—pourrait produire de véritables améliorations algorithmiques. Mais la supply chain ne profitera de ces améliorations que si le reste de l’architecture est sain : une sémantique correcte, des objectifs économiques, une gestion robuste de l’incertitude, et une boucle d’exécution qui transforme de manière fiable les recommandations en actions.
En d’autres termes, considérez les LLMs de la même manière que vous traitez tout outil puissant mais faillible : comme un accélérateur pour les personnes qui construisent des systèmes, et non comme une couche de vernis sur des processus défaillants. Considérez-les comme un moyen de réduire le coût de la rigueur, et non comme un moyen de la contourner.
La supply chain ne manque pas de mots. Elle manque de bonnes décisions. Les LLMs sont exceptionnels pour produire des mots. Ils peuvent nous aider à construire de meilleurs systèmes, plus rapidement. Mais si nous confondons éloquence et exactitude, nous obtiendrons simplement des erreurs livrées dans une prose améliorée—et à une vitesse supérieure.
