Transcription complète
Conor Doherty: Ceci est Supply Chain Breakdown, et pendant environ 30 minutes, nous allons déconstruire le battage autour des digital twins, en particulier dans la supply chain. Je m’appelle Conor. Je suis le Directeur de la Communication chez Lokad, et à mes côtés en studio, à ma gauche comme toujours, l’inénarrable Joannes Vermorel, fondateur et CEO de Lokad.
Avant de commencer, laissez un commentaire ci-dessous — tout d’abord, d’où venez-vous, et ensuite, que pensez-vous des digital twins ? N’oubliez pas, nous sommes là pour discuter de vos préoccupations. De plus, posez vos questions dès que vous en avez. Si vous entendez quelque chose que Joannes dit et que vous souhaitez le questionner à ce sujet, n’hésitez pas à le mentionner ci-dessous et je lui poserai la question dans une vingtaine de minutes environ.
Et sur ce, plus de temps perdu. Joannes, élimine le battage autour des digital twins car je sais que cela circule depuis un moment, mais pose le décor : qu’est-ce qu’un digital twin en termes simples et élémentaires ? Et également, quel est le problème que, du moins selon certains, les digital twins sont censés résoudre ?
Joannes Vermorel: Alors, en ce qui concerne ce que sont les digital twins, je dirais que si l’on prend la version des consultants — qui n’est pas celle que je suivrais — ils vous diraient : c’est une représentation exacte de votre supply chain, entièrement digitale, qui vous permet de projeter à peu près n’importe quoi dans le futur. Comme si vous disposiez d’une simulation complète, parfaitement précise, de l’intégralité de votre supply chain. Du moins, c’est la perspective idéale pour vos digital twins en supply chain.
Et l’idée des digital twins existe également dans d’autres domaines, où il est parfois possible d’obtenir une simulation très précise d’un système physique. Maintenant, en pratique, qu’est-ce que c’est ? En pratique, ce n’est rien d’autre qu’un simulateur Monte Carlo reconditionné. Ces simulateurs existent depuis environ quatre décennies. La caractéristique principale est qu’ils sont très, très faciles à mettre en œuvre, et c’est relativement amusant, en tant que projet ludique, de réaliser un simulateur Monte Carlo d’un système tant que vous ne vous souciez pas vraiment de quelque chose comme la précision des simulations.
Conor Doherty: Je vais intervenir immédiatement car tu as soulevé quelques points intéressants. Tu as donné au moins deux applications. L’une concernait la manière dont les digital twins pourraient être commercialisés dans un contexte de supply chain — c’est une catégorie. Mais tu as dit qu’il existait une application préexistante ou plus pérenne ; tu parlais des produits physiques. Pourrais-tu clarifier un peu cette distinction ?
Joannes Vermorel: Oui. Je veux dire, l’idée d’avoir des simulateurs repose sur trois concepts clés : micro-analytique, discret et stochastique. Voilà trois aspects. Quand on pense aux simulateurs Monte Carlo, ce sont ces trois aspects que l’on retrouve.
Micro-analytique signifie que vous souhaitez décomposer votre système en éléments analogues à des atomes ou en éléments très, très petits qui présentent des comportements simples régis par des lois simples que vous pouvez quantifier entièrement. C’est là l’approche micro-analytique. Ensuite, discret : pour votre ordinateur, vous allez supposer que tout se comporte par incréments réguliers — dans la supply chain, cela a du sens — y compris pour la dimension temporelle. Vous allez donc dire : “D’accord, je vais créer un simulateur qui fonctionne avec une étape par jour,” ou quelque chose de similaire.
Et enfin, l’aspect stochastique : pour certains comportements, vous allez simplement ajouter un peu d’aléatoire. C’est pourquoi je parle d’un simulateur Monte Carlo. Vous attribuez à certains comportements un caractère aléatoire ou stochastique, puis vous pouvez exécuter votre simulateur de nombreuses fois pour projeter, en théorie, un état futur de votre supply chain, ou du moins, pour faire avancer la simulation dans le temps. Et parce qu’il est censé être un digital twin de votre supply chain, il représente l’avenir de votre supply chain.
Conor Doherty: Merci, et je pense que cela soulève en réalité un point clé quant à la façon dont la conversation peut être découpée. Quand on parle d’utiliser un digital twin, disons, dans la fabrication ou la réparation, vous pouvez dire : “J’ai un digital twin. C’est une représentation déterministe d’un appareil complet.” Ainsi, un A320 comporte environ 320 000 pièces. Vous savez combien il y a de pièces ; vous pouvez le modéliser ; c’est fixe. Il s’agit là d’une réplique digitale ou d’une représentation digitale d’un produit ou d’une propriété physique et connue.
Dans quelle mesure pouvez-vous appliquer ce même concept à un réseau réparti géographiquement comme une supply chain qui englobe non seulement des éléments physiques tels que les produits et les camions et autres, mais aussi des comportements, des tendances, de la politique — autant de facteurs ayant un impact sur ces éléments ?
Joannes Vermorel: Le principal problème réside dans les lois qui régissent vos atomes, vos unités élémentaires de simulation. Dans le monde physique, vous pouvez littéralement appliquer l’électromagnétisme et autres pour obtenir une évolution physiquement précise de votre système, car vous partez du principe que si vous décomposez suffisammement les choses, ce qui reste obéira à des lois très, très bien établies. Si vous souhaitez décrire un fluide circulant dans divers tubes, par exemple, vous disposez des équations microfluidiques et vous pouvez réaliser une simulation par éléments finis.
Mais l’idée clé ici est que cela suppose que vous disposez de lois régissant les éléments de votre système qui sont quasiment parfaitement connues, et que le seul point à régler est la résolution de votre simulation, qui pourrait ne pas être suffisante pour être ultra précise. Le problème avec un digital twin dans la supply chain, c’est que le défi n’est pas tant la résolution. Le défi est qu’il n’est absolument pas clair que vous disposiez de connaissances préalables pertinentes sur les comportements de ces unités simples, car ces unités — disons que vous souhaitez simuler un fournisseur — ne sont absolument pas simples.
Il n’y a pas — vous pouvez faire autant d’hypothèses simplistes sur le comportement de ce fournisseur que vous le souhaitez, mais ce n’est pas parce que vous venez d’inventer une hypothèse concernant cette entité que cela sera vrai. Et il en va de même pour tout : clients, entrepôts, itinéraires qui relient l’ensemble de votre supply chain, etc. Il existe donc un problème fondamental : oui, vous pouvez créer un simulateur en décomposant votre système et en imaginant des comportements pour tous les atomes, mais ces comportements présentent-ils une quelconque validité ? C’est le grand, grand défi, et c’est généralement quelque chose qui n’est jamais abordé avec ces digital twins en supply chain — la justesse de la modélisation.
Conor Doherty: La justesse et d’autres indicateurs, nous y reviendrons, mais je souhaite approfondir un peu plus. En fait, je vais vous lire une définition très limpide. Quoi qu’il en soit, c’est une définition claire, et j’aimerais avoir votre réaction. Je ne vais pas encore vous dire de qui elle provient — vous pourrez deviner plus tard — mais elle fait fort. Donc, citation: “Les digital twins peuvent être utilisés pour modéliser l’interaction entre des processus physiques et digitaux tout au long de la supply chain, de l’idéation du produit et la fabrication jusqu’à l’entreposage et la distribution, des achats en magasin ou en ligne jusqu’à l’expédition et les retours. Ainsi, les digital twins offrent une vision claire d’un processus optimal de supply chain end-to-end.” Maintenant, quelle est votre opinion à ce sujet ? Sur quelles parties êtes-vous en désaccord ?
Joannes Vermorel: Cette définition ne dit rien, si ce n’est l’intention. Elle se contente de dire: “D’accord, l’intention est d’avoir quelque chose qui réalise tout ce que cette définition décrit,” c’est-à-dire une représentation end-to-end précise de bla, bla, bla. C’est l’intention. Elle n’explique rien quant à la manière dont cela est fait. Et mon message est: la manière compte.
Vous pouvez inventer ou rêver de nombreux outils incroyables. J’aimerais — qu’est-ce qu’un assistant IA parfait ? C’est quelque chose qui possède une intelligence bien supérieure à celle d’un humain et qui peut faire tout ce qu’un humain peut faire, mais en mieux. D’accord, je viens de définir ce qu’aurait été un assistant IA parfait. Cela signifie-t-il qu’il existe déjà quelque chose de semblable ? Le problème, c’est que si vous définissez quelque chose par son intention, cela n’indique rien quant à la faisabilité ou au fait que cette chose soit même réelle.
Donc oui, nous avons une belle définition intentionnelle. Et moi, quand je dis “simulateur Monte Carlo,” j’ai fait exactement le contraire. J’ai commencé par, “D’accord, que font les entreprises en coulisses lorsqu’elles utilisent le mot à la mode ‘digital twin’ ?” Et ma réponse est, pour autant que je puisse en juger: un simulateur Monte Carlo. Pourquoi ? Parce que c’est extrêmement simple à mettre en œuvre. Littéralement, un étudiant en première année d’informatique peut le faire en quelques jours — probablement même les plus brillants le feraient en un après-midi. Et oui, tant que vous ne vous souciez pas de la pertinence de votre simulation par rapport au monde réel, c’est super simple à réaliser.
Conor Doherty: Pour en revenir, tu parles de l’intention. Le but, du moins tel que présenté par de nombreuses personnes, serait — pour te donner matière à réfléchir — que de nombreux fournisseurs, consultants et promoteurs d’un digital twin soutiendraient qu’un digital twin améliore la prise de décision en fournissant effectivement — même si c’est via Monte Carlo — un bac à sable dans lequel tu peux jouer avec des scénarios du type “Et si le fournisseur est en retard ? Et si le canal de Suez était bloqué ?” ou autre.
Joannes Vermorel: Une intelligence artificielle générale améliore la rentabilité de toute entreprise — par définition. Si vous disposez de quelque chose d’aussi intelligent qu’un humain mais sans salaire, oui, cela améliorera la rentabilité. D’accord. Mais revenons à la question : cette chose est-elle disponible, et quelles sont les techniques ? Ces parties la présentent comme un fait accompli : elle est déjà là, nous l’avons, elle possède toutes ces bonnes propriétés. Mais, attendez — qu’avez-vous en coulisses ?
Et mon message est: pour autant que je sache, littéralement toutes les entreprises que j’ai vues promouvoir des digital twins n’avaient rien d’autre que de naïfs simulateurs Monte Carlo, ce qui, à mon sens, relève d’une sophistication de niveau ludique. C’est fantaisiste. C’est le genre d’exercice que je donnerais à des étudiants en première année d’informatique. Oui, c’est amusant à mettre en œuvre, et c’est facile. Mais le problème est, encore une fois, que c’est totalement inventé.
Oui, vous pouvez décomposer votre supply chain en une liste de SKUs, une liste de clients, une liste de fournisseurs, et attribuer des comportements à toutes ces entités, puis laisser la simulation s’exécuter — absolument. Mais est-ce réellement correct ? C’est une question de taille. Pour faire une analogie : prenez SimCity 2000, ce jeu vidéo — un vieux. Ils disposent d’un éditeur de cartes. Vous pouvez littéralement éditer une carte qui ressemblerait exactement à Paris, tracer toutes les routes telles qu’elles sont à Paris — presque, car là encore, vous avez le problème de la discrétisation, donc ce ne sont pas exactement les mêmes routes, mais suffisamment proches. Ensuite, vous dites: “Cette zone, c’est du logement, celle-ci, c’est de l’industrie, celle-là, c’est du commerce.” Oui, vous pourriez faire cela, puis laisser la simulation du jeu progresser.
Cela vous donne-t-il une simulation précise de l’avenir de l’environnement urbain de Paris ? Ma réponse est absolument non — surtout quand Godzilla intervient ; c’est une catastrophe qui survient dans le jeu. Ce n’est pas parce que c’est très facile à créer. Encore une fois, je le répète: il est très facile de créer des simulateurs, et c’est amusant. La question est vraiment: pourquoi pensez-vous même que cela aura une quelconque précision ?
Dans d’autres domaines, tels que les sciences physiques — par exemple les sciences des matériaux — votre simulateur est efficace car il respecte fondamentalement les lois de la physique, lesquelles sont très bien connues et vérifiées. Ainsi, fondamentalement, vos comportements ne sont pas inventés : vous prenez littéralement des manuels de physique et appliquez l’électromagnétisme ou la dynamique des fluides, par exemple, et ce sont ces comportements qui régissent vos éléments, vos atomes. Mais dans un digital twin pour la supply chain, vous devez inventer et imaginer ces comportements — ou les découvrir d’une certaine manière — et c’est une partie très, très délicate. À ma connaissance, les digital twins pour la supply chain — les fournisseurs, les personnes qui en font la promotion — ne disent vraiment rien à ce sujet, et c’est là tout le cœur du problème.
Conor Doherty: Tu as mentionné la précision et la justesse, et encore, pour répliquer — au fait, cette définition précédente venait de McKinsey, celle avec laquelle tu étais en désaccord. Et d’une part à l’autre, parce que maintenant c’est BCG — oh, désolé, tu veux dire quelque chose ?
Joannes Vermorel: Encore une fois, le problème est qu’ils se contentent de décrire l’intention. Lorsqu’il s’agit d’une technologie, je préfère vraiment me concentrer sur le comment. Définir une technologie par l’intention de ce que vous souhaitez accomplir, c’est bien, mais cela ne permet pas de raisonner sur le fait que ce soit une bonne technologie ou non. Je ne suis pas en désaccord avec l’intention — l’intention est bonne, oui. La question est : disposez-vous d’une définition qui vous permette d’identifier si cette technologie est meilleure ou moins bonne qu’une autre pour votre supply chain ?
Conor Doherty: Sur ce, selon, encore une fois, nous citant les sources — d’après Boston Consulting Group, les entreprises avec des digital twins ont amélioré la précision de leurs prévisions de 20 à 30%. Je veux dire, n’est-ce pas quelque chose que la plupart des entreprises souhaiteraient avoir à tout prix ? Se trompent-elles à poursuivre cela ?
Joannes Vermorel: Autant que je sache, les digital twins n’ont jamais fait surface dans aucune compétition de prévisions. Il existe de nombreuses compétitions de prévisions ; il y a des dizaines de techniques utilisées pour améliorer les prévisions dans ces compétitions. Je n’ai jamais entendu parler de quoi que ce soit en rapport avec les digital twins qui aurait le moindre impact sur la prévision.
Vous voyez donc, le problème est que, pour moi, parce qu’ils ne définissent pas quelles techniques ils évoquent réellement, cela peut être n’importe quoi. Mon point de vue — et c’est un point de vue empirique — est que les entreprises qui commercialisent des digital twins se contentent essentiellement de construire des simulateurs Monte Carlo, lesquels n’apportent pas une précision supérieure. Encore une fois, je ne sais pas comment ces chiffres ont été obtenus, mais la réalité est que ce n’est même pas du tout dans le domaine de ce qui peut réellement améliorer la précision des prévisions.
Conor Doherty: Mais il y a un autre point à considérer, sans doute, et c’est: une plus grande précision conduit-elle nécessairement à une meilleure prise de décision, qui est ce que l’on cherche à obtenir avec le digital twin? Il y a donc un usage instrumental et ensuite il y a ce que vous essayez réellement d’accomplir — l’objectif, la finalité.
Joannes Vermorel : Oui. Si nous disons que ce que nous voulons, c’est de meilleures décisions avec un rendement supérieur sur investissement, alors conceptuellement le digital twin pourrait dire : si j’ai une politique A, je la fais passer dans mon digital twin, j’en évalue le rendement sur investissement ; puis j’ai une politique B, je fais la même chose, et je choisirai la politique qui régit ma décision et qui me donne simplement un taux de rendement supérieur. Conceptuellement, d’accord – pourquoi pas ?
Mais encore, tout cela repose sur le fait que votre digital twin vous fournit une évaluation économique correcte. Ainsi, ce problème de précision se traduit en termes de dollars : vous avez un taux de rendement pour la politique A, un taux de rendement pour la politique B. Mais encore : est-ce que votre digital twin possède une quelconque forme de justesse ? Pourquoi lui feriez-vous confiance ? C’est une question très compliquée.
Nous pouvons revenir à SimCity 2000 et à Paris. Je peux laisser le jeu avancer avec différents niveaux de taxation pour la ville – cela existe dans le jeu. Mais est-ce que cette chose me dira quelque chose de très précis sur la ville de Paris ? Je pense qu’il serait manifestement complètement insensé de penser qu’un jeu vidéo puisse être utilisé pour modéliser avec précision l’évolution d’une métropole réelle. C’est le même genre de problème que j’ai avec ces digital twins pour supply chain. À moins que vous n’ajoutiez beaucoup de choses, ce que vous avez, c’est simplement un vœu pieux.
Oui, ce serait vraiment super si nous avions quelque chose qui fasse tout cela avec une grande précision. Si vous me dites que cette simulation Monte Carlo est quelque chose de révolutionnaire qui va rendre cela possible – je ne le pense vraiment pas. Au mieux, c’est un tout petit ingrédient : super simple. Ce serait un peu comme dire : « Computers are going to be involved. » Oui, probablement. C’est une bonne idée de faire intervenir des ordinateurs, tout comme utiliser un simulateur Monte Carlo est une bonne technique. C’est minime ; je ne vais pas contester. C’est simplement très, très superficiel. C’est un peu comme, « Il vaudrait mieux utiliser du métal pour une voiture. » Certes, le métal sera impliqué, mais cela ne vous donnera pas une voiture.
Conor Doherty : D’accord. Je sais que nous pourrions en parler indéfiniment, mais encore, le sujet tel qu’annoncé portait spécifiquement sur les digital twins. Il y a quelques jours, vous avez lancé un sondage sur LinkedIn où vous demandiez à votre audience : “What are the biggest blockers for digital twins?” parce qu’un grand nombre de personnes qui regardent, et qui verront cela plus tard, sont des entreprises qui envisagent d’adopter cette technologie ou qui l’adoptent déjà.
Joannes Vermorel : D’abord, un simulateur Monte Carlo à l’échelle de votre supply chain n’est en réalité rien d’autre qu’un modèle de prévision probabiliste. C’est littéralement ce que c’est. Quand nous parlons de prévision probabiliste, nous ne sommes pas très précis sur les modèles sous-jacents réellement utilisés pour cela. Dans le cours, je donne une série d’exemples sur comment vous pouvez construire ces modèles. Mais lorsque vous dites simplement “prévision probabiliste”, vous ne dites rien du tout sur le modèle lui-même.
Vous pouvez construire votre modèle de prévision probabiliste avec un simulateur Monte Carlo. Vous laissez simplement la simulation s’exécuter, vous rassemblez vos distributions de probabilité empiriques, et si vous exécutez vos simulations des milliers de fois, vous finirez par obtenir de jolis histogrammes multidimensionnels qui vous fourniront vos distributions de probabilité, et voilà, vous avez votre prévision probabiliste. Ainsi, il existe une dualité entre un simulateur Monte Carlo et une prévision probabiliste. À partir des probabilités, vous pouvez générer des déviations – ce qui vous donne ces comportements stochastiques. Mais si vous avez ces comportements stochastiques, vous pouvez les exécuter et obtenir les distributions de probabilité. Fondamentalement, c’est la même chose.
Cependant, il y a un point clé : dès que vous commencez à considérer votre simulateur Monte Carlo comme un moteur de prévision probabiliste, alors vous pouvez en évaluer la précision – ce qui est également très important et, selon moi, très insuffisant chez les fournisseurs qui promeuvent les digital twins. Ils ne mentionnent même jamais le fait que ce qu’ils ont est un moteur de prévision probabiliste, et qu’il doit donc être évalué en termes de précision avec des métriques pertinentes pour la prévision probabiliste.
Conor Doherty : D’accord. Je sais que nous pourrions en parler indéfiniment, mais encore, le thème tel qu’annoncé portait spécifiquement sur les digital twins. Il y a quelques jours, vous avez lancé un sondage sur LinkedIn où vous demandiez à votre audience, “What are the biggest blockers for digital twins?” parce qu’un grand nombre de personnes qui regardent, et qui verront cela plus tard, sont des entreprises qui envisagent ou qui adoptent déjà cette technologie.
Dans ce sondage, 52 % des votants ont indiqué que le plus grand obstacle était des données désordonnées ou incomplètes. Tout d’abord – et c’est quelque chose dont je me souviens que vous avez parlé il y a quelques années – en considérant la taille des entreprises qui envisageraient un digital twin, il s’agit de très grandes entreprises ; vraisemblablement, elles disposent d’ERP coûteux et fiables. La question devient donc : comment des données désordonnées ou incomplètes peuvent-elles constituer un obstacle à quelque chose que vous avez dit être assez simple à mettre en œuvre ?
Joannes Vermorel : Ici, si par données manquantes vous entendez les comportements – ce qui caractérise le comportement de toutes ces entités – je dirais que oui. Mais il n’a jamais, je pense, été attendu de trouver dans un ERP les paramètres pouvant caractériser le comportement de l’un de vos clients, par exemple. Donc, je ne pense pas que c’est ce que les gens veulent dire – sans aucun doute.
Mon point de vue est que les données sont toujours le bouc émissaire. Lorsque la technologie est extrêmement superficielle et qu’elle ne délivre pas ce qui était promis, invariablement ce sont les mauvaises données que l’on blâme. Cela ne correspond vraiment pas à l’expérience que nous avons chez Lokad. Mon expérience est que les entreprises réalisant un chiffre d’affaires annuel supérieur à un milliard de dollars ou d’euros disposent de données excellentes. Elles savent à peu près exactement ce qu’elles vendent, elles savent exactement ce qu’elles achètent, et elles savent exactement ce qu’elles ont en stocks. Oui, il y a des erreurs de saisie ici et là, mais nous parlons d’environ 0,1 % d’erreurs de ce type.
Dans l’ensemble, en ce qui concerne la précision des données, celle-ci est parfaite. L’ensemble du flux de marchandises – depuis l’acquisition, le transport, la transformation jusqu’à la distribution – est connu avec une quasi-certitude. La qualité de ces données est très élevée. Oui, certaines autres données peuvent être un peu plus floues, surtout lorsqu’il s’agit de plans promotionnels ou de ce genre de choses, mais l’historique transactionnel fondamental est excellent. Techniquement, c’est la seule chose dont vous avez réellement besoin pour construire un simulateur. Vous disposeriez de ces systèmes qui évoluent dans le temps, générant des transactions, et votre digital twin devrait être capable d’en être le miroir dans le futur et de prédire l’état futur de vos systèmes.
Mais ce n’est pas le cas. Voilà le problème. Selon eux, ils ne le sont pas, et les données en sont alors mises pour compte. Chaque fois que j’entends ces lamentations concernant les problèmes de données, ce que j’entends, c’est une technologie inadéquate qui génère essentiellement des résultats déplorables, et les gens disent : “Oh, la sortie est de la camelote”, mais cela doit être parce que l’entrée est de la camelote – le problème GIGO, garbage in, garbage out. Mais que se passe-t-il si l’entrée est parfaitement correcte ? Mon point de vue est que l’entrée est en réalité parfaitement correcte – à peu près – et l’a été pendant les deux dernières décennies – pour la grande majorité des grandes entreprises.
Cela ne signifie pas qu’il n’existe aucun défi en matière de données. L’un des enjeux principaux est que, lorsque vous consultez un ERP, il y a 10 000 tables, et chacune comporte environ 50 champs. C’est un défi énorme. Mais cela ne signifie pas que les données qui s’y trouvent sont de la camelote. Cela reflète simplement le fait que vos systèmes d’entreprise n’ont pas été conçus pour faciliter la vie d’un data scientist afin de concevoir votre simulateur Monte Carlo. C’est un problème complètement différent.
Conor Doherty : En parlant de problèmes, un autre problème cité par 21 % des votants était un modèle fragile ou bogué. Vous avez précédemment dit que l’installation de ceci n’était pas particulièrement compliquée – c’est le genre de chose que vous pourriez confier à un étudiant en première année d’informatique. Donc, encore une fois, je reviens à la question : si vous avez des entreprises valant plusieurs milliards de dollars, et un exercice qui est un processus très simple, pourquoi un cinquième des répondants affirme-t-il que le problème réside dans la modélisation ?
Joannes Vermorel : Les simulateurs Monte Carlo sont conceptuellement très simples, et en termes d’implémentation, extrêmement directs. Cependant, vous allez très rapidement être confronté à de très basiques problèmes de performance. Permettez-moi d’expliquer. De combien de SKU parlons-nous ? Un million – à peu près, pour une entreprise de plus d’un milliard. Disons un million de SKU.
Ensuite, combien de cycles CPU faut-il pour simuler un SKU, rien que pour le comportement dont nous parlons ? Disons 10 cycles CPU minimum, et nous sommes super efficaces si nous affirmons cela. Puis, combien de jours ? Supposons que nous ayons un simulateur qui s’exécute un jour à la fois – 100 jours. Nous parlons donc de 1 million multiplié par 1 000 – soit un milliard d’opérations CPU – pour simuler 100 jours, en gros.
Le problème, c’est que c’est stochastique – c’est un simulateur micro-analytique, discret, stochastique – donc vous devez répéter vos exécutions. Combien de fois devez-vous exécuter votre simulation pour obtenir des statistiques suffisamment fiables ? À cause du problème de résolution, vous devez répéter au moins mille fois. Nous sommes donc à un mille milliards d’opérations. Ce n’est pas un problème avec les ordinateurs modernes, à moins que vous ne fassiez quelque chose de vraiment sophistiqué avec l’ordinateur, comme du parallélisme, etc. Il s’agit d’environ 20 minutes de calcul, avec de nombreuses solutions pour paralléliser le tout, mais les personnes qui se contentent d’un simulateur rapide et simple ne vont pas faire tout cela. Nous supposons donc quelque chose de simple – très bien. Vingt minutes ne semblent pas trop mal – sauf
Excepté que maintenant, vous souhaitez vérifier des options. Par exemple, “Dois-je placer cette unité ici ou cette unité là ?” Chaque option que vous explorez vous obligera à supporter ce coût, car vous exécuterez votre simulation pour votre scénario de référence, puis vous essayez quelque chose et vous la relancez. Si vous avez simplement une préoccupation très globale – comme “Et si le coût du capital de travail change ? Je veux juste connaître le résultat” – c’est acceptable : vous l’exécutez deux fois et vous obtenez la différence.
Mais si vous commencez à poser des questions telles que “Combien d’unités dois-je mettre dans chaque point de vente ?” vous devrez exécuter votre simulateur des milliers et des milliers de fois – une pour chaque micro-question à laquelle vous souhaitez répondre. Soudainement, les gens se rendent compte : “Oh, 20 minutes, c’est tellement lent. Je dois exécuter ceci des centaines de milliers de fois, voire des millions – une pour chaque SKU ou quelque chose du genre.” Ensuite, cela devient un gros problème. La solution devient alors : adopter cette approche micro-analytique où je simulais tout au niveau du SKU – ah, cela devient un véritable casse-tête. “Nous allons donc avoir une simulation à un niveau beaucoup plus agrégé.”
Mais maintenant, nous avons un autre gros problème, à savoir que tout reposait sur le fait que les comportements de vos éléments de simulation sont corrects au niveau du SKU. Il était déjà difficile d’affirmer qu’il est simple de disposer de comportements évidents applicables. Si vous commencez à agréger au niveau du DC, qu’est-ce qui vous fait penser que vous pourrez jamais établir les lois correctes qui régissent l’afflux et l’écoulement dans un centre de distribution ? C’est une partie très complexe de votre réseau. Il n’y a aucune raison de penser que des lois simplistes vont régir cela. De même, si nous parlons d’un client en B2B – un client qui commande des tonnes de produits très divers à des horaires variés, etc.
Donc, vous aviez ce problème de simulateur. Le simulateur est simple au niveau micro, mais vous vous retrouvez très rapidement confronté à des problèmes de performance. Vous pouvez ré-agréger, mais si vous ré-agrégez, alors le problème d’avoir des comportements précis pour votre simulateur est absolument amplifié.
Conor Doherty : Je pense qu’un point essentiel, au cas où ce serait la première fois que les gens nous entendent en parler, c’est que, lorsqu’on parle de décisions, celles évoquées dans le cadre de Lokad ne se limitent pas à “Eh bien, j’ai une unité ; je l’envoie là ou pas.” Je veux dire qu’il existe des combinaisons pour chacune de ces décisions. Je pourrais en envoyer une là ou aucune. Je peux en envoyer une là et une ici ou aucune, ou deux là et une ici, ou liquider, ou encore augmenter le prix d’une unité ici, à cet endroit. La perspective locale est donc incroyablement granulaire, au cas où les gens n’auraient pas compris à quel point il s’agit d’un niveau de détail extrême. C’est comme au microscope – c’est aussi granulaire.
Et d’ailleurs, la raison pour laquelle nous sommes si granulaires, c’est que, si nous revenons à la modélisation de ces comportements, si nous voulons avoir une quelconque confiance dans le résultat économique, nous devons être au niveau le plus bas. C’est le seul domaine où nous pouvons réellement recoupler combien cela a coûté à produire, combien le client paie pour cette unité, etc.
Joannes Vermorel : Exactement. C’est la raison pour laquelle nous sommes au niveau le plus bas. Le problème des initiatives de digital twin est qu’elles se rendent très rapidement – avec leurs simulateurs Monte Carlo – compte qu’elles ont des problèmes de performance, et passent donc directement à un niveau d’agrégation supérieur, plus facile à calculer. Mais alors, le problème d’obtenir des comportements corrects devient absolument énorme, et oui, vous vous retrouvez avec un simulateur potentiellement très imprécis. Il n’est même pas clair pourquoi vous devriez croire en ce simulateur dès le départ, puisque ces comportements qui régissent ces entités sont entièrement inventés.
Conor Doherty : Encore, nous reviendrons dans une autre intervention sur la valeur des décisions – nous en avons parlé récemment avec Adam Dejans Jr et Warren Powell. Pour ceux qui veulent en savoir plus, consultez la vidéo la plus récente ici. Pour continuer : un autre obstacle majeur à l’adoption mentionné par votre audience était la gestion du changement. C’est quelque chose qui ressort typiquement pour pratiquement n’importe quelle technologie. Mais quand nous parlons de quelque chose – vous avez utilisé une image miroir – vous l’avez décrit comme étant essentiellement, si cela fonctionne bien, vous avez une image miroir de ce que vous possédez déjà. La question est donc : pourquoi une image miroir d’un état préexistant nécessiterait-elle une gestion du changement étendue ?
Joannes Vermorel: Si vous aviez — et je mets vraiment au défi que les entreprises qui poussent ces technologies le fassent — mais si vous aviez quelque chose qui soit un prédicteur à haute dimension de l’état futur de votre supply chain, ce qui est, de manière inspirante, ce à quoi ces jumeaux numériques aspirent, alors l’aspect intéressant est que, si c’est fait de bout en bout, vous pouvez — il n’y a plus de silos —. Vous pouvez littéralement simuler l’effet de chaque changement de politique à effectuer dans chaque silo, et ensuite vous obtenez le taux de rendement pour l’ensemble de l’entreprise. C’est très attractif. Je ne le nie pas. Lokad est sur la même voie.
Ce que je pense encore — et cela requiert donc énormément de gestion du changement —, c’est que si vous avez une technologie qui vous permet de contourner tous les silos de l’entreprise, alors cela va créer des problèmes partout. Soudainement, vous vous rendrez compte que la politique adoptée par, disons, cette division est en réalité préjudiciable à l’entreprise dans son ensemble. Peut-être améliore-t-elle les KPIs de cette division, mais c’est au détriment de la performance de l’ensemble. Donc oui, on peut naturellement s’attendre à ce que la gestion du changement et la résistance soient très élevées. Cette partie, je pense, est raisonnable.
Conor Doherty: Joannes, nous parlons depuis environ 35 minutes, me semble-t-il, et il y a en fait un certain nombre de questions auxquelles il faut répondre. Je vais bientôt passer aux questions du public. Veuillez poser vos questions avant que nous ne terminions. Mais, en guise de réflexion finale sur cette section — vu tout ce dont nous avons discuté —, quel est votre conseil d’adieu aux responsables et aux dirigeants de supply chain qui sont soit en train d’essayer d’adopter cette technologie, soit d’envisager son adoption ?
Joannes Vermorel: Vous devez vraiment regarder sérieusement ce qui se trouve sous le capot. Mon point de vue est — tout comme pour le “demand sensing”, il existe d’autres mots à la mode qui circulent dans les cercles de la supply chain — que, dans le cas du demand sensing, il n’y a rien ; dans le cas des jumeaux numériques, la plupart du temps, il y a un peu quelque chose : ce n’est qu’un simulateur de Monte Carlo. Mais vous devez vraiment remettre en question ce qui se trouve sous le capot.
Oui, les gens peuvent construire toutes sortes de belles interfaces utilisateur dessus. Ils peuvent avoir des graphiques sophistiqués. S’ils affichent une carte, vous pouvez avoir une carte animée et tout le reste. C’est vendre un rêve. Vous devez vraiment vérifier ce qu’il y a dans cette chose. Appliquez la sympathie mécanique : vous devriez demander à votre fournisseur, “Veuillez me dire pourquoi cette chose va fonctionner.” Et ne confondez pas l’intention. Les gens disent, “Cela optimise ceci.” Non, attendez. Vous optimisez le profit — l’optimisation étant le résultat. Je ne vous interroge pas sur le résultat. Vous me vendez quelque chose de très positif pour l’entreprise, mais dites-moi comment c’est réalisé numériquement.
Enquêtez. Si au final vous constatez que ce ne sont que des règles codées en dur appliquées en séquence pour ce simulateur de Monte Carlo, alors l’empereur n’a pas de vêtements. C’est tout simplement très, très superficiel.
Conor Doherty: Pour conclure sur vos propres remarques : j’avais dit au début que c’était une conversation que vous aviez eue avant mon arrivée ici. En août 2022, sur ce sujet, vous aviez dit, et je cite, “Ma perception des jumeaux numériques est que ce n’est qu’un de ces mots à la mode. On dirait rien de plus qu’un simulateur glorifié.” Alors, en conclusion, au bout de ces trois dernières années, tenez-vous toujours ces propos ?
Joannes Vermorel: Étant donné l’intention — “jumeau numérique” —, je n’ai vu aucun fournisseur proposer quelque chose de véritablement portant une substance technologique. Je ne remets pas en cause l’intention. Si demain quelqu’un venait dire, “J’ai un jumeau numérique, mais au lieu de réaliser simplement un simulateur de Monte Carlo super naïf qu’un étudiant en première année d’informatique pourrait programmer, j’ai cette nouvelle technique incroyable, et je vous en fournis le plan ; c’est très sophistiqué, et cela accomplit les choses d’une manière bien meilleure que ce naïf de Monte Carlo,” je dirais, “Oui, absolument, peut-être que c’est réellement pertinent.”
C’est comme si quelqu’un disait “L’AGI est super bien,” je dirais, “Oui, l’AGI est super bien. En avez-vous un ?” Donc encore une fois, je ne remets pas en cause l’intention associée à cela. Je remets vraiment en cause l’ensemble des techniques qui se trouvent en dessous. Et pour l’instant, trois ans plus tard, je n’ai toujours pas vu de fournisseur proposer des techniques que je qualifierais de remarquables.
Y a-t-il un fournisseur — et je serais très intéressé si le public pouvait proposer quelque chose — qui dirait, “Joannes, regardez ces techniques qui sont vraiment remarquables ; elles repoussent l’état de l’art en matière de simulations stochastiques” ? Je dirais que je suis tout ouïe. Je n’ai pas vu cela.
Conor Doherty: C’est un défi ouvert. Si quelqu’un a quelque chose à partager avec Joannes, contactez-le et faites-le. Quoi qu’il en soit, Joannes, je vais passer aux questions du public. Il y en a quelques-unes à traiter. Je vais lire — certaines sont assez longues — alors soyez attentifs.
De Philip : prenons l’incident du canal de Suez comme exemple. Supposons que mon modèle estime un délai d’approvisionnement d’un mois pour l’expédition de marchandises de l’Australie vers la France, en prenant en compte les conditions normales de trafic. Que se passerait-il si un navire bloquait le canal de façon inattendue, comme cela s’est produit auparavant ? Le modèle ne pourrait pas prévoir cette perturbation, et je subirais alors de sérieux retards et difficultés. Question : comment gérer de tels événements imprévisibles dans la modélisation de la supply chain ?
Joannes Vermorel: C’est une excellente question. Ici, en fait, le simulateur de Monte Carlo fournit une perspective qui n’est pas trop mauvaise, et c’est exactement la même approche que celle utilisée par Lokad. Il s’agit d’une approche programmatique. Le simulateur de Monte Carlo est fondamentalement un paradigme programmatique : vous implémentez, dans un langage de programmation relativement général, vos règles qui caractérisent les comportements.
Chez Lokad, la manière de procéder est que la majeure partie des comportements est apprise à partir de données historiques. Mais comme c’est un programme, vous pouvez interférer avec ce programme et introduire une interférence, à la fois intentionnelle et programmatique. Pourquoi est-ce nécessaire ? Parce que vous devez vous assurer d’augmenter sélectivement les délais d’approvisionnement projetés pour les fournisseurs qui vont souffrir du problème dans ce canal.
Par exemple, si vous avez des fournisseurs en Asie qui expédient leurs marchandises par avion, vous ne souhaitez pas augmenter leur délai d’approvisionnement. Il faut donc être très prudent, et vous devrez peut-être consulter les données historiques pour identifier quels fournisseurs avaient un délai correspondant à un envoi par bateau — ou disposer de cette information —, puis vous pourrez, de manière programmatique, ajouter ce petit coup de pouce supplémentaire. Je pense qu’avoir une approche programmatique ici est un avantage. Du côté des jumeaux numériques, je pense qu’ils abordent le problème sous le bon angle, c’est-à-dire à travers des méthodes programmatiques, tout comme le fait Lokad. Sur ce point, c’est bien. La situation est en fait plus claire comparée à d’autres approches non programmatiques qui comptent uniquement sur des menus et des boutons pour couvrir chaque situation éventuelle. Si vous avez accès à un langage de programmation au cœur de votre modèle, vous pouvez toujours implémenter des règles sur mesure correspondant aux événements inattendus.
Conor Doherty: Merci. Je poursuis — de Manuel : “En théorie, cette technologie, les jumeaux numériques, pourrait avoir un impact majeur sur l’aide à la décision dans la supply chain. Que pensez-vous de l’évolution de cette technologie et de la réalisation de son potentiel ?” Je pense que nous en avons déjà un peu parlé.
Joannes Vermorel: Comme direction inspirante, l’idée d’avoir une modélisation de bout en bout de la supply chain est une excellente idée. Lokad est également dans cette voie. Quels sont les ingrédients clés ? Il y a de nombreux ingrédients essentiels à cela : le differentiable programming en est un ; l’algèbre des variables aléatoires en est un autre ; l’algèbre relationnelle aussi en fait partie. Vous avez des tonnes d’ingrédients.
L’idée d’utiliser des simulateurs de Monte Carlo — soit dit en passant, Lokad utilise également des composants de Monte Carlo — ouvre des perspectives très intéressantes. Si vous avez des comportements aléatoires — intentionnellement aléatoires —, une partie de ce processus Monte Carlo crée un problème très subtil en matière de débogage. Vous lancez votre programme : il plante — c’est mauvais. Vous le lancez de nouveau : il ne plante pas — et c’est pire, car vous avez un bug qui apparaît de façon intermittente, et quand vous souhaitez l’examiner de près, il a disparu. Chez Lokad, nous appelons ces problèmes des “Heisenbugs.” C’est un bug qui apparaît de façon intermittente ; quand on y regarde de plus près, il disparaît.
C’est un défaut majeur de l’approche simpliste classique de votre simulateur de Monte Carlo. C’est quelque chose que le secteur financier a rencontré au début des années 90. Ce que vous recherchez, c’est du pseudo-aléatoire et, en réalité, quelque chose de complètement déterministe, même si vous exécutez une simulation de Monte Carlo. Cela nécessite des astuces relativement ingénieuses. De plus, vous souhaitez que ce déterminisme soit maintenu même en cas de cloud computing distribué, de sorte que l’ensemble du système s’exécute sur de nombreux CPU et éventuellement sur de nombreuses machines — parce que, comme je l’ai souligné, si vous êtes sur un seul CPU et en mono-thread, vous rencontrerez très rapidement des problèmes de performance. Aucun souci : vous pouvez étendre votre système sur de nombreux CPU et machines. Mais cela nécessite des outils tels que, même en cas de bugs ou de plantages, l’ensemble du système demeure complètement déterministe.
Mon point de vue est qu’il y a énormément de choses à concevoir pour ces jumeaux numériques que les fournisseurs peuvent apporter. Ce que je dis — l’essentiel de ma critique — c’est que les personnes qui se présentent avec cette étiquette, ce mot à la mode, n’apportent pas beaucoup de substance. C’est très, très superficiel, et quand on regarde ce qui se cache derrière — demandez une démo —, on ne voit qu’une simulation de Monte Carlo très simpliste et naïve, qui ne va tout simplement pas fournir ce type de résultats.
Conor Doherty: Parfaite transition vers la troisième question, merci. De Shashank — pardonnez-moi si je prononce mal — : “Joannes, quelle est votre opinion sur le simulateur de Monte Carlo par rapport aux modèles stochastiques agentiques dans les réseaux de supply chain ?”
Joannes Vermorel: Vous avez plusieurs angles. Le Monte Carlo est un outil très utile ; c’est une astuce numérique. Il est très utile — tout comme l’algèbre linéaire, c’est une astuce fondamentale très basique. En soi, il est très utile. Maintenant, dans un simulateur de Monte Carlo, toute l’intelligence réside dans les comportements que vous simulez, car essentiellement, un simulateur de Monte Carlo, c’est : j’ai un million d’items ; je prends l’item un ; j’applique mon comportement ; j’obtiens une déviation — un comportement non déterministe — donc j’obtiens la déviation en sortie de l’élément un. Puis je répète pour l’élément deux, trois, etc., et ce, pour chaque période.
Le détail, ce sont ces comportements, et c’est vraiment, vraiment complexe. L’avantage de l’astuce numérique du Monte Carlo est qu’elle s’intègre assez bien dans le monde très quantitatif et à haute dimension de la supply chain. Si vous parlez d’IA agentique — ce serait, par exemple, les LLM, pour être précis — les LLM, quant à eux, traitent des séquences de symboles. Un LLM — un large language model — est une machine qui prédit de futures séquences de symboles, appelées tokens.
En termes d’adéquation avec les données dont vous disposez, ce n’est vraiment pas évident. Un LLM n’est pas exactement le meilleur choix pour votre système de supply chain. Mon avis est que, dans l’état futur des technologies de la supply chain, les simulateurs de Monte Carlo seront-ils présents dans 10 ans ? Oui, parce que c’est un bloc de construction aussi basique. C’est comme dire, “Aurez-vous des racines carrées dans vos systèmes ?” Oui. L’IA agentique, comme les LLM — je pense qu’ils ont leur place, mais leur place pourrait ne pas être au cœur de l’évaluation quantitative de la supply chain. Leur place est plutôt en périphérie, là où il faut interagir avec les clients, les fournisseurs, ou éventuellement même des tiers, et où se déroulent des conversations textuelles. C’est une manière d’apporter certaines données ou de compléter certaines interactions, mais ce n’est pas exactement le cœur de l’optimisation elle-même.
Conor Doherty: Merci. Je poursuis avec Tao : “À votre avis, le véritable problème des jumeaux numériques réside-t-il dans le fait que les outils actuellement utilisés pour simuler la supply chain sont défaillants, ou est-ce que le bon outil pour l’optimisation de la supply chain pourrait ne pas nécessiter du tout de jumeau numérique ?”
Joannes Vermorel: C’est exactement la première raison. Ces outils sont défaillants — et d’une manière très spécifique. C’est un outil super superficiel, facile à mettre en œuvre. Les gens doivent penser que dans le monde des enterprise software, il y a une tentation : dès que vous finalisez un accord avec le conseil d’administration, avec un PDG, le prix affiché sera très élevé — même si ce que vous vendez n’est essentiellement rien. Cela peut paraître étrange, mais dans le domaine du software d’entreprise, vous allez vendre quelque chose à plus de 100 000 $ par an, peu importe ce que vous vendez réellement.
Il y a donc ce flux constant de personnes qui arrivent sur le marché et disent, “Regardez, j’ai ce truc, et si je peux créer suffisamment d’engouement à son sujet, certaines entreprises vont payer pour cela.” À leur échelle, c’est une goutte d’eau dans l’océan. Si vous êtes une entreprise de plus d’un milliard de dollars et que vous payez 100 000 $ par an pour un gadget, ce n’est pas énorme ; cela ne mettra pas en péril votre rentabilité. Mais par conséquent, les PDG et les conseils — les dirigeants de niveau C en général — n’ont pas forcément le temps de s’attarder sur les détails de ce qu’ils achètent exactement, surtout si le prix n’est pas exorbitant. Pour une entreprise, 100 000 $ ne représentent pas un montant exorbitant. Pour ce prix-là, le PDG d’une entreprise d’un milliard de dollars ne va pas passer des jours à valider ces choses ; cela devra être une décision très rapide.
La conséquence est que, malheureusement, vous avez beaucoup d’acteurs qui proposent une technologie très simple — super simpliste — mais qui ont maîtrisé l’art de l’emballage. Vous avez votre simulateur de Monte Carlo — franchement, ce n’est rien, c’est insignifiant — mais il bénéficie d’un bel emballage sophistiqué. Ensuite, vous ajoutez, exactement comme dans la définition que nous avons reçue, une explication du type “Qui ne voudrait pas avoir quelque chose qui va optimiser ci et ça, et améliorer ci et ça, pour la fabrication et tout le reste ?” Oui. “Quel est le prix de ce gadget qui rend toute mon entreprise meilleure ?” “Tel ou tel — 100 000 $.” “D’accord, c’est super bon marché. Essayons-le.”
Mais mon message est le suivant : examinez ce qu’il y a sous le capot. Est-ce vraiment du concret ? Un emballage ne suffit pas. Ce que je constate, c’est un schéma : “jumeau numérique” est arrivé avec un packaging. Une fois que vous avez vu un autre fournisseur avec un tel emballage, le reproduire est simple, car l’emballage représente littéralement ce que vous voyez de l’extérieur. Ce qu’il y a à l’intérieur — si ce n’est qu’un simulateur de Monte Carlo —, vous pouvez embaucher un ingénieur logiciel et cette solution sera mise en œuvre en quelques jours.
Tous ces ingrédients ensemble créent cette tentation d’aller sur le marché avec la bonne offre, de prospecter les C-levels partout, et si vous avez suffisamment de chance, vous conclurez une série d’affaires — et puis, bam, vous avez une entreprise. Je dis simplement que c’est typiquement le genre d’anti-patterns que je constate dans le domaine des logiciels d’entreprise.
Conor Doherty: Merci. Et Joannes, voici la dernière question — j’ai l’impression de pouvoir deviner la réponse, mais elle vient de Murthy : “Comment les digital twins peuvent-ils évoluer d’outils de surveillance réactifs en agents proactifs de prise de décision dans des écosystèmes d’entreprise réels?”
Joannes Vermorel: Tout d’abord, dans cette définition et la configuration technique que je viens de présenter, qu’est-ce qui rend le digital twin réactif plutôt que proactif ? Conceptuellement, rien. Pourquoi n’utiliseriez-vous pas ce simulateur—super granular, end-to-end—pour remettre en question de manière proactive chaque politique que vous vous apprêtez à appliquer pour votre supply chain ? Évidemment, cet outil est censé être proactif.
Ainsi, si la manière dont il est utilisé en pratique n’est pas proactive, il faut se demander pourquoi. Sur le papier, un simulateur de Monte Carlo : vous disposez de quelque chose d’assez précis et représentatif de votre supply chain et de son état futur ; vous pouvez—parce qu’il est programmatique—injecter n’importe quelle politique. Fantastique. Cela signifie que vous pouvez tout remettre en question ; évidemment, il est censé être proactif.
Mais ce n’est pas le cas. Pourquoi cela ? Analysez sous un angle logiciel : que font-ils, comment cela est-il implémenté ? Cela vous donnera la réponse. La réponse est : nous sommes revenus à un million de SKUs, 10 cycles CPU, 100 jours, etc. Vous obtenez : oui, cet outil peut vous fournir une simulation de ce qui va se passer, mais à moins de fournir d’importants efforts d’ingénierie—ce que ces fournisseurs ne font pas—vous obtiendrez une réponse toutes les, disons, 20 minutes, voire une réponse par heure si ce n’est pas super bien implémenté.
Soudain, vous vous rendez compte que vous avez un problème, car comment pouvez-vous piloter quoi que ce soit lorsque vous faites face à ce type de problème de performance ? Je ne parle même pas du problème de précision du modèle—simplement de la performance de base en termes de ressources informatiques à injecter. C’est un problème très réel. C’est pourquoi les gens finissent par adopter une approche très réactive, car ils réalisent que l’ensemble est super lent. Vous essayez essentiellement de poser des millions de questions à votre système, mais si vous devez attendre 20 minutes pour chaque réponse, c’est incroyable—et vous devez poser ces un million de questions chaque jour.
Vous vous retrouvez avec des problèmes très basiques. Si vous ré-agrégez les données, soudain vous ne pouvez pas poser de questions réellement importantes, car vous vous situez à un niveau d’agrégation qui ne reflète plus les décisions que vous devez prendre, telles que: “Dois-je produire ceci ? Dois-je déplacer les stocks là-bas ? Dois-je augmenter le prix de ces produits ?” Soudain, si vous êtes à un niveau agrégé—par exemple, si vous voulez raisonner sur la tarification d’une catégorie de produits—il n’a pas vraiment de sens de dire: “Je vais augmenter ou diminuer le prix de tous les produits de cette catégorie.” Vous voudrez probablement différencier en fonction des caractéristiques de chaque produit. Mais encore une fois, cela va à l’encontre de l’idée de tout agréger.
Conor Doherty: Pour faire un rapide plug, je sais que vous couvrez en détail le concept d’optionnalité décisionnelle inhérent au flux des biens physiques—votre définition de supply chain. C’est abordé, je pense, dans Lecture 1.2, “Supply Chain in a Nutshell.”
C’est littéralement le premier—d’accord. Eh bien, regardez au moins les deux premiers si rien d’autre, car ensuite vous passez à “Quantitative Supply Chain in a Nutshell.” C’est plutôt bien—mieux que plutôt bien. Quoi qu’il en soit, Joannes, cela fait une heure que nous discutons. Nous sommes à court de questions, et maintenant nous manquons de temps. Comme toujours, merci beaucoup de m’avoir rejoint et pour vos réponses.
Et à tous les autres, merci d’être présents. Merci pour vos questions. Si ce n’est pas déjà fait, suivez Lokad sur LinkedIn, s’il vous plaît. Et si vous n’êtes pas connecté avec nous, envoyez-nous une demande de connexion. Nous sommes toujours ravis de discuter des problématiques de supply chain. Et sur ce, à tous, je dis: retournez au travail.
