Les paradigmes de programmation en tant que théorie de la Supply Chain - Cours 1.4

00:28 Introduction
00:43 Robert A. Heinlein
03:03 L’histoire jusqu’à présent
06:52 Une sélection de paradigmes
08:20 Analyse statique
18:26 Programmation de tableau
28:08 Compatibilité matérielle
35:38 Programmation probabiliste
40:53 Programmation différentiable
55:12 Versionnage du code+données
01:00:01 Programmation sécurisée
01:05:37 En conclusion, l’outillage compte aussi en Supply Chain
01:06:40 Prochaine conférence et questions du public

Description

Alors que la théorie de la supply chain mainstream peine à s’imposer dans les entreprises en général, un outil ; à savoir Microsoft Excel, a connu un succès opérationnel considérable. La réimplémentation des recettes numériques de la théorie mainstream de la supply chain via des tableurs est triviale, pourtant, ce n’est pas ce qui s’est passé en pratique malgré la connaissance de la théorie. Nous démontrons que les tableurs ont gagné en adoptant des paradigmes de programmation qui se sont avérés supérieurs pour obtenir des résultats de supply chain.

Transcription complète

Bonjour à tous, bienvenue à cette série de conférences sur la supply chain. Je suis Joannes Vermorel, et aujourd’hui je vais présenter ma quatrième conférence : Les paradigmes de programmation pour la Supply Chain.

Alors quand on me demande, “M. Vermorel, quels sont selon vous les domaines les plus intéressants en termes de connaissances en supply chain ?” une de mes premières réponses est généralement les paradigmes de programmation. Et puis, pas trop souvent, mais assez souvent, la réaction de la personne à qui je parle est, “Les paradigmes de programmation, M. Vermorel ? De quoi diable parlez-vous ? Comment cela est-il même vaguement pertinent pour la tâche à accomplir ?” Et ces sortes de réactions, évidemment, elles ne sont pas si fréquentes, mais quand elles se produisent, elles me rappellent invariablement cette citation complètement incroyable de Robert A. Heinlein, qui est considéré comme le doyen des écrivains de science-fiction.

Heinlein a une citation fantastique sur l’homme compétent, qui souligne l’importance de la compétence dans divers domaines, surtout en supply chain où nous avons des problèmes diaboliques entre les mains. Ces problèmes sont presque aussi difficiles que la vie elle-même, et je crois qu’il vaut vraiment la peine d’explorer l’idée des paradigmes de programmation, car cela pourrait apporter beaucoup de valeur à votre supply chain.

Jusqu’à présent, dans la première conférence, nous avons vu que les problèmes de supply chain sont diaboliques. Quiconque parle de solutions optimales passe à côté du sujet ; il n’y a rien qui se rapproche même vaguement de l’optimalité. Dans la deuxième conférence, j’ai exposé la Supply Chain Quantitative, une vision avec cinq exigences clés pour l’excellence en gestion de la supply chain. Ces exigences ne sont pas suffisantes en elles-mêmes, mais elles ne peuvent être contournées si vous voulez atteindre l’excellence.

Dans la troisième conférence, j’ai discuté de la livraison de produits logiciels dans le contexte de l’optimisation de la supply chain. J’ai défendu la proposition que l’optimisation de la supply chain nécessite un produit logiciel pour être abordée correctement de manière capitaliste, mais vous ne pouvez pas trouver un tel produit sur l’étagère. Il y a trop de diversité, et les défis auxquels nous sommes confrontés vont bien au-delà des technologies que nous avons à l’heure actuelle. Donc, cela va être, par nécessité, quelque chose de complètement sur mesure. Ainsi, s’il s’agit d’un produit logiciel qui va être sur mesure pour l’entreprise ou la supply chain d’intérêt, il y a une question de quels sont les outils appropriés pour livrer réellement ce produit. Cela m’amène au sujet d’aujourd’hui : l’outil approprié commence par les bons paradigmes de programmation, car nous allons devoir programmer ce produit d’une manière ou d’une autre.

Jusqu’à présent, nous avons besoin de capacités de programmation pour traiter le côté optimisation du problème, à ne pas confondre avec le côté gestion. Ce que nous avons vu, qui était le sujet de ma conférence précédente, c’est que Microsoft Excel a été le gagnant jusqu’à présent. Des très petites entreprises aux très grandes entreprises, il est omniprésent, il est utilisé partout. Même dans les entreprises qui ont investi des millions de dollars dans des systèmes super intelligents, Excel règne toujours, et pourquoi ? Parce qu’il a les bonnes propriétés de programmation. Il est très expressif, agile, accessible et maintenable. Cependant, Excel n’est pas la fin du jeu. Je crois fermement que nous pouvons faire beaucoup plus, mais nous avons besoin d’avoir les bons outils, la bonne mentalité, les bonnes idées et les bons paradigmes de programmation.

Les paradigmes de programmation peuvent sembler excessivement obscurs au public, mais c’est en fait un domaine d’étude qui a été intensivement étudié au cours des cinq dernières décennies. Il y a eu une immense quantité de travail accompli dans ce domaine d’étude. Il n’est pas largement connu d’un public plus large, mais il existe des bibliothèques entières remplies de travaux de haute qualité qui ont été réalisés par de nombreuses personnes. Donc aujourd’hui, je vais introduire une série de sept paradigmes que Lokad a adoptés. Nous n’avons inventé aucune de ces idées ; nous les avons prises de personnes qui les ont inventées avant nous. Tous ces paradigmes ont été mis en œuvre dans le produit logiciel de Lokad, et après près d’une décennie d’exploitation de Lokad en production, en exploitant ces paradigmes, je crois qu’ils ont été absolument essentiels à notre succès opérationnel jusqu’à présent.

Procédons à travers cette liste avec l’analyse statique. Le problème ici est la complexité. Comment gérez-vous la complexité dans la supply chain ? Vous allez être confronté à des systèmes d’entreprise qui ont des centaines de tables, chacune avec des dizaines de champs. Si vous envisagez un problème aussi simple que le réapprovisionnement des stocks dans un entrepôt, vous avez tellement de choses à prendre en compte. Vous pouvez avoir des MOQs, des remises sur quantité, des prévisions de demande, des prévisions de délais d’approvisionnement, et toutes sortes de retours. Vous pouvez avoir des limitations d’espace de stockage, des limites de capacité de réception, et des dates d’expiration qui rendent certains de vos lots obsolètes. Donc, vous vous retrouvez avec des tonnes de choses à considérer. Dans la supply chain, l’idée de “bouger vite et casser des choses” n’est tout simplement pas la bonne mentalité. Si vous commandez par inadvertance pour un million de dollars de marchandises dont vous n’avez pas du tout besoin, c’est une erreur très coûteuse. Vous ne pouvez pas avoir un logiciel qui gère votre supply chain, qui prend des décisions de routine, et quand il y a un bug, cela coûte des millions. Nous devons avoir quelque chose avec un très haut degré de justesse par conception. Nous ne voulons pas découvrir les bugs en production. C’est très différent de votre logiciel moyen où un crash n’est pas grave.

En ce qui concerne l’optimisation de la supply chain, ce n’est pas votre problème habituel. Si vous venez de passer une commande massive et incorrecte à un fournisseur, vous ne pouvez pas simplement les appeler une semaine plus tard pour dire : “Oh, mon erreur, non, oubliez ça, nous n’avons jamais commandé ça.” Ces erreurs vont coûter beaucoup d’argent. L’analyse statique est appelée ainsi parce qu’il s’agit d’analyser un programme sans l’exécuter. L’idée est que vous avez un programme écrit avec des instructions, des mots-clés, et tout, et sans même exécuter ce programme, pouvez-vous déjà dire si le programme présente des problèmes qui auraient presque certainement un impact négatif sur votre production, en particulier votre production de supply chain ? La réponse est oui. Ces techniques existent, et elles sont mises en œuvre et extrêmement précieuses.

Pour donner un exemple, vous pouvez voir une capture d’écran d’Envision sur l’écran. Envision est un langage de programmation spécifique à un domaine qui a été conçu pendant près d’une décennie par Lokad et est dédié à l’optimisation prédictive de la supply chain. Ce que vous voyez est une capture d’écran de l’éditeur de code d’Envision, une application web que vous pouvez utiliser en ligne pour éditer du code. La syntaxe est fortement influencée par Python. Dans cette petite capture d’écran, avec seulement quatre lignes, j’illustre l’idée que si vous écrivez une grande partie de la logique pour le réapprovisionnement des stocks dans un entrepôt, et que vous introduisez certaines variables économiques, comme les ruptures de prix, à travers une analyse logique du programme, vous pouvez voir que ces ruptures de prix n’ont aucune relation avec les résultats finaux qui sont retournés par le programme, qui sont les quantités à réapprovisionner. Ici, vous avez un problème évident. Vous avez introduit une variable importante, les ruptures de prix, et ces ruptures de prix n’ont logiquement aucune influence sur les résultats finaux. Donc ici, nous avons un problème qui peut être détecté par une analyse statique. C’est un problème évident car si nous introduisons des variables dans le code qui n’ont aucun impact sur la sortie du programme, alors elles ne servent à rien du tout. Dans ce cas, nous sommes confrontés à deux options : soit ces variables sont en réalité du code mort, et le programme ne devrait pas compiler (vous devriez simplement vous débarrasser de ce code mort pour réduire la complexité et ne pas accumuler de complexité accidentelle), soit c’était une véritable erreur et il y a une variable économique importante qui aurait dû être intégrée dans votre calcul, mais vous avez laissé tomber la balle par distraction ou pour une autre raison.

L’analyse statique est absolument fondamentale pour atteindre un certain degré de correction par conception. Il s’agit de corriger les choses au moment de la compilation, lorsque vous écrivez le code, même avant de toucher aux données. Si des problèmes apparaissent lorsque vous les exécutez, il y a de fortes chances que vos problèmes ne se produisent que pendant la nuit, lorsque vous avez le lot nocturne qui gère le réapprovisionnement de l’entrepôt. Le programme est susceptible de fonctionner à des heures étranges lorsque personne ne le surveille, donc vous ne voulez pas qu’il se bloque alors qu’il n’y a personne devant le programme. Il devrait se bloquer au moment où les gens écrivent réellement le code.

L’analyse statique a de nombreux objectifs. Par exemple, chez Lokad, nous utilisons l’analyse statique pour l’édition WYSIWYG des tableaux de bord. WYSIWYG signifie “what you see is what you get.” Imaginez que vous construisez un tableau de bord pour le reporting, avec des graphiques en ligne, des graphiques à barres, des tableaux, des couleurs et divers effets de style. Vous voulez pouvoir le faire visuellement, ne pas ajuster le style de votre tableau de bord à travers le code, car c’est très fastidieux. Tous les paramètres que vous avez mis en place vont être réinjectés dans le code lui-même, et cela se fait par une analyse statique.

Un autre aspect chez Lokad, qui peut ne pas être d’une telle importance pour la supply chain dans son ensemble mais qui est certainement crucial pour entreprendre le projet, était de travailler avec un langage de programmation appelé Envision que nous sommes en train de concevoir. Nous savions dès le premier jour, il y a presque une décennie, que des erreurs allaient être commises. Nous n’avions pas une boule de cristal pour avoir la vision parfaite dès le premier jour. La question était, comment pouvons-nous nous assurer que nous pouvons corriger ces erreurs de conception dans le langage de programmation lui-même aussi commodément que possible ? Ici, Python était un conte d’avertissement pour moi.

Python, qui n’est pas un nouveau langage, a été lancé pour la première fois en 1991, il y a presque 30 ans. La migration de Python 2 à Python 3 a pris presque une décennie à l’ensemble de la communauté, et c’était un processus cauchemardesque, très douloureux pour les entreprises impliquées dans cette migration. Ma perception était que le langage lui-même n’avait pas assez de constructions. Il n’a pas été conçu de manière à ce que vous puissiez migrer des programmes d’une version du langage de programmation à une autre version. Il était en fait extrêmement difficile de le faire de manière complètement automatisée, et c’est parce que Python n’a pas été conçu avec l’analyse statique à l’esprit. Lorsque vous avez un langage de programmation pour la supply chain, vous voulez vraiment un langage qui a une excellente qualité en termes d’analyse statique parce que vos programmes seront longs à vivre. Les supply chains n’ont pas le luxe de dire, “Attendez trois mois ; nous sommes en train de réécrire le code. Attendez-nous ; la cavalerie arrive. Ça ne va juste pas fonctionner pendant quelques mois.” C’est littéralement comme réparer un train pendant que le train roule à pleine vitesse, et vous voulez réparer le moteur pendant que le train fonctionne. C’est à quoi ressemble la réparation de choses de la supply chain qui sont en fait en production. Vous n’avez pas le luxe de simplement mettre le système en pause ; il ne fait jamais de pause.

Le deuxième paradigme est la programmation de tableau. Nous voulons avoir la complexité sous contrôle, car c’est un grand thème récurrent dans les supply chains. Nous voulons avoir une logique où nous n’avons pas certaines classes d’erreurs de programmation. Par exemple, chaque fois que vous avez des boucles ou des branches qui sont écrites explicitement par des programmeurs, vous vous exposez à des classes entières de problèmes très difficiles. Il devient extrêmement difficile lorsque les gens peuvent simplement écrire des boucles arbitraires d’avoir des garanties sur la durée du calcul. Bien que cela puisse sembler être un problème de niche, ce n’est pas tout à fait le cas dans l’optimisation de la supply chain.

En pratique, disons que vous avez une chaîne de vente au détail. À minuit, ils auront complètement consolidé toutes les ventes de l’ensemble du réseau, et les données seront consolidées et transmises à une sorte de système pour l’optimisation. Ce système aura exactement une fenêtre de 60 minutes pour faire les prévisions, l’optimisation des stocks, et les décisions de réaffectation pour chaque magasin du réseau. Une fois que c’est fait, les résultats seront transmis au système de gestion d’entrepôt afin qu’ils puissent commencer à préparer tous les envois. Les camions vont être chargés, peut-être à 5h00 du matin, et à 9h00, les magasins ouvrent avec la marchandise déjà reçue et mise en rayon.

Cependant, vous avez un timing très strict, et si votre calcul dépasse cette fenêtre de 60 minutes, vous mettez en péril l’exécution de toute la supply chain. Vous ne voulez pas quelque chose où vous allez juste découvrir en production combien de temps les choses prennent. Si vous avez des boucles où les gens peuvent décider combien d’itérations ils vont avoir, il est très difficile d’avoir une preuve de la durée de votre calcul. Gardez à l’esprit que nous parlons ici d’optimisation de la supply chain. Vous n’avez pas le luxe de faire une revue par les pairs et de tout vérifier deux fois. Parfois, en raison de la pandémie, certains pays ferment tandis que d’autres rouvrent de manière assez erratique, généralement avec un préavis de 24 heures. Vous devez réagir rapidement.

Alors, la programmation par tableaux est l’idée que vous pouvez opérer directement sur des tableaux. Si nous regardons le morceau de code que nous avons ici, c’est du code Envision, le DSL de Lokad. Pour comprendre ce qui se passe, vous devez comprendre que lorsque j’écris “orders.amounts”, ce qui vient est une variable et les “orders” sont en fait une table au sens d’une table relationnelle, comme une table dans votre base de données. Par exemple, ici à la première ligne, “amounts” serait une colonne dans la table. À la ligne un, ce que je fais, c’est que je dis littéralement pour chaque ligne de la table des commandes, je vais simplement prendre la “quantité”, qui est une colonne, et la multiplier par le “prix”, et ensuite j’obtiens une troisième colonne qui est générée dynamiquement, qui est “amount”.

Au fait, le terme moderne pour la programmation par tableaux est aussi connu sous le nom de programmation par data frame. Le domaine d’étude est assez ancien ; il remonte à trois ou quatre décennies, peut-être même quatre ou cinq. Il a été connu sous le nom de programmation par tableaux même si de nos jours les gens sont généralement plus familiers avec l’idée de data frames. À la ligne deux, ce que nous faisons, c’est que nous faisons un filtre, tout comme SQL. Nous filtrons les dates, et il se trouve que la table des commandes a une date. Elle va être filtrée, et je dis “date qui est supérieure à aujourd’hui moins 365”, donc c’est des jours. Nous gardons les données de l’année dernière, et ensuite nous écrivons “products.soldLastYear = SUM(orders.amount)”.

Maintenant, la chose intéressante est que nous avons ce que nous appelons une jointure naturelle entre les produits et les commandes. Pourquoi ? Parce que chaque ligne de commande est associée à un produit et un seul produit, et un produit est associé à zéro ou plusieurs lignes de commande. Dans cette configuration, vous pouvez directement dire, “Je veux calculer quelque chose au niveau du produit qui est juste une somme de ce qui se passe au niveau des commandes,” et c’est exactement ce qui est fait à la ligne neuf. Vous remarquerez peut-être que la syntaxe est très épurée ; vous n’avez pas beaucoup d’accidentels ou de technicités. Je soutiendrais que ce code est presque entièrement dépourvu d’accidentels en ce qui concerne la programmation par data frame. Ensuite, aux lignes 10, 11 et 12, nous mettons simplement une table en affichage sur notre tableau de bord, ce qui peut être fait très commodément : “LIST(PRODUCTS)”, puis “TO(products)”.

Il y a de nombreux avantages à la programmation par tableau pour les supply chains. Tout d’abord, elle élimine des classes entières de problèmes. Vous n’aurez pas de bugs de décalage d’un dans vos tableaux. Il sera beaucoup plus facile de paralléliser et même de distribuer le calcul. C’est très intéressant car cela signifie que vous pouvez écrire un programme et faire exécuter le programme non pas sur une machine locale mais directement sur une flotte de machines qui vivent dans le cloud, et d’ailleurs, c’est exactement ce qui se fait chez Lokad. Cette parallélisation automatique est d’un intérêt supérieur.

Vous voyez, la façon dont cela fonctionne est que lorsque vous faites de l’optimisation de la supply chain, vos schémas de consommation typiques en termes de matériel informatique sont super intermittents. Si je reviens à l’exemple que je donnais sur la fenêtre de 60 minutes pour les réseaux de vente au détail pendant le réapprovisionnement des magasins, cela signifie qu’il y a une heure par jour où vous avez besoin de puissance de calcul pour faire tous vos calculs, mais le reste du temps, les 23 autres heures, vous n’en avez pas besoin. Donc ce que vous voulez, c’est un programme qui, lorsque vous êtes sur le point de l’exécuter, va se répartir sur de nombreuses machines et puis, une fois qu’il a fini, il va simplement libérer toutes ces machines pour que d’autres calculs puissent avoir lieu. L’alternative serait d’avoir de nombreuses machines que vous louez et payez toute la journée mais que vous n’utilisez que 5% du temps, ce qui est très inefficace.

Cette idée que vous pouvez distribuer sur de nombreuses machines rapidement et de manière prévisible, puis abandonner la puissance de traitement, nécessite le cloud dans une configuration multi-locataire et une série d’autres choses en plus que Lokad fait. Mais avant tout, il faut la coopération du langage de programmation lui-même. C’est quelque chose qui n’est tout simplement pas réalisable avec un langage de programmation générique comme Python, car le langage lui-même ne se prête pas à ce genre d’approche très intelligente et pertinente. Il s’agit de plus que de simples astuces ; il s’agit littéralement de diviser vos coûts de matériel informatique par 20, d’accélérer massivement l’exécution et d’éliminer des classes entières de bugs potentiels dans votre supply chain. C’est révolutionnaire.

La programmation par tableau existe déjà dans de nombreux aspects, comme dans NumPy et pandas en Python, qui sont si populaires pour le segment du public des data scientists. Mais la question que j’ai pour vous est, si c’est si important et utile, pourquoi ces choses ne sont-elles pas des citoyens de première classe du langage lui-même ? Si tout ce que vous faites est de passer par NumPy, alors NumPy devrait être un citoyen de première classe. Je dirais que vous pouvez faire encore mieux que NumPy. NumPy ne concerne que la programmation par tableau sur une machine, mais pourquoi ne pas faire de la programmation par tableau sur une flotte de machines ? C’est beaucoup plus puissant et beaucoup plus adéquat lorsque vous avez un cloud avec une capacité matérielle accessible.

Alors, quel va être le goulot d’étranglement dans l’optimisation de la supply chain ? Il y a ce dicton de Goldratt qui dit, “Toute amélioration apportée à côté du goulot d’étranglement dans une supply chain est une illusion,” et je suis tout à fait d’accord avec cette affirmation. Réalistement, lorsque nous voulons faire de l’optimisation de la supply chain, le goulot d’étranglement sera les personnes, et plus spécifiquement, les Supply Chain Scientists qui, malheureusement pour Lokad et mes clients, ne poussent pas sur les arbres.

Le goulot d’étranglement est les Supply Chain Scientists, les personnes qui peuvent élaborer les recettes numériques qui prennent en compte toutes les stratégies de l’entreprise, les comportements adverses des concurrents, et qui transforment toute cette intelligence en quelque chose de mécanique qui peut être exécuté à grande échelle. La tragédie de la manière naïve de faire de la data science, lorsque j’ai commencé mon doctorat, que je n’ai d’ailleurs jamais terminé, était que je pouvais voir que tout le monde dans le laboratoire faisait littéralement de la data science. La plupart des gens écrivaient du code pour un certain type de modèle d’apprentissage machine avancé, ils appuyaient sur entrée et commençaient à attendre. Si vous avez un grand ensemble de données, disons 5-10 gigaoctets, ce ne sera pas en temps réel. Ainsi, tout le laboratoire était rempli de personnes qui écrivaient quelques lignes, appuyaient sur entrée, puis allaient prendre une tasse de café ou lire quelque chose en ligne. Ainsi, la productivité était extrêmement faible.

Lorsque j’ai créé ma propre entreprise, j’avais en tête que je ne voulais pas finir par payer une armée de gens super intelligents qui passent la majeure partie de leur journée à siroter du café, en attendant que leurs programmes se terminent pour qu’ils puissent avoir des résultats et avancer. En théorie, ils pourraient paralléliser beaucoup de choses à la fois et faire des expériences, mais en pratique, je n’ai jamais vraiment vu cela. Intellectuellement, lorsque vous êtes engagé dans la recherche d’une solution à un problème, vous voulez tester votre hypothèse, et vous avez besoin du résultat pour avancer. Il est très difficile de faire plusieurs tâches à la fois sur des choses très techniques et de poursuivre plusieurs pistes intellectuelles en même temps.

Cependant, il y avait une lueur d’espoir. Les data scientists, et maintenant les Supply Chain Scientists chez Lokad, n’en finissent pas d’écrire mille lignes de code puis de dire “s’il vous plaît, exécutez”. Ils ajoutent généralement deux lignes à un script qui fait mille lignes de long, puis ils demandent à ce que le script soit exécuté. Ce script est exécuté contre exactement les mêmes données qu’ils viennent d’exécuter quelques minutes auparavant. C’est presque exactement la même logique, à part ces deux lignes. Alors, comment pouvez-vous traiter des téraoctets de données en quelques secondes au lieu de plusieurs minutes ? La réponse est, si pour l’exécution précédente du script, vous avez enregistré toutes les étapes intermédiaires du calcul et les avez mises en stockage (typiquement des disques à semi-conducteurs ou SSD), qui sont très bon marché, rapides et pratiques.

La prochaine fois que vous exécutez votre programme, le système remarquera que c’est presque le même script. Il va faire une différence, et voir qu’en termes de graphe de calcul, c’est presque identique, à part quelques bits. En termes de données, c’est généralement 100% identique. Parfois, il y a quelques changements, mais presque rien. Le système va auto-diagnostiquer que vous n’avez que quelques choses à calculer, donc vous pouvez avoir les résultats en quelques secondes. Cela peut considérablement augmenter la productivité de votre Supply Chain Scientist. Vous pouvez passer de personnes qui appuient sur entrée et attendent 20 minutes pour le résultat à quelque chose où elles appuient sur entrée et 5 ou 10 secondes plus tard, elles ont le résultat et peuvent avancer.

Je parle de quelque chose qui peut sembler super obscur, mais en pratique, nous parlons de quelque chose qui a un impact de 10x sur la productivité. C’est énorme. Alors ce que nous faisons ici, c’est utiliser une astuce intelligente que Lokad n’a pas inventée. Nous substituons une ressource informatique brute, qui est le calcul, par une autre, qui est la mémoire et le stockage. Nous avons les ressources informatiques fondamentales : le calcul, la mémoire (soit volatile, soit persistante), et la bande passante. Ce sont les ressources fondamentales que vous payez lorsque vous achetez des ressources sur une plateforme de cloud computing. Vous pouvez en fait substituer une ressource à une autre, et l’objectif est d’obtenir le meilleur rendement pour votre argent.

Quand les gens disent que vous devriez utiliser le calcul en mémoire, je dirais que c’est absurde. Si vous dites calcul en mémoire, cela signifie que vous mettez l’accent sur une ressource par rapport à toutes les autres. Mais non, il y a des compromis, et l’intéressant est que vous pouvez avoir un langage de programmation et un environnement qui rendent ces compromis et ces perspectives plus faciles à mettre en œuvre. Dans un langage de programmation généraliste, il est possible de le faire, mais vous devez le faire manuellement. Cela signifie que la personne qui le fait doit être un ingénieur logiciel professionnel. Un Supply Chain Scientist ne va pas effectuer ces opérations de bas niveau avec les ressources informatiques fondamentales de votre plateforme. Cela doit être conçu au niveau du langage de programmation lui-même.

Maintenant, parlons de la programmation probabiliste. Dans la deuxième conférence où j’ai introduit la vision pour la Supply Chain Quantitative, ma première exigence était que nous devons regarder tous les futurs possibles. La réponse technique à cette exigence est la prévision probabiliste. Vous voulez traiter des futurs où vous avez des probabilités. Tous les futurs sont possibles, mais ils ne sont pas tous également probables. Vous devez avoir une algèbre où vous pouvez faire des calculs avec incertitude. L’une de mes grandes critiques d’Excel est qu’il est extrêmement difficile de représenter l’incertitude dans un tableur, que ce soit Excel ou toute autre saveur basée sur le cloud plus moderne. Dans un tableur, il est très difficile de représenter l’incertitude parce que vous avez besoin de quelque chose de mieux que des nombres.

Dans ce petit extrait, j’illustre l’algèbre des variables aléatoires, qui est une caractéristique native d’Envision. À la ligne un, je génère une distribution de Poisson qui est discrète, avec une moyenne de 2, et je la mets dans la variable X. Ensuite, je fais la même chose pour une autre distribution de Poisson, Y. Ensuite, je calcule Z comme la multiplication de X fois Y. Cette opération, la multiplication de variables aléatoires, peut sembler très bizarre. Pourquoi avez-vous même besoin de ce genre de chose d’un point de vue supply chain ? Laissez-moi vous donner un exemple.

Disons que vous êtes dans le marché secondaire de l’automobile et que vous vendez des plaquettes de frein. Les gens n’achètent pas des plaquettes de frein à l’unité ; ils en achètent soit deux, soit quatre. Alors la question est, si vous voulez faire une prévision, vous voudrez peut-être prévoir les probabilités que les clients se présentent pour acheter un certain type de plaquettes de frein. Ce sera votre première variable aléatoire qui vous donne la probabilité d’observer zéro unité de demande, une unité de demande, deux, trois, quatre, etc. pour les plaquettes de frein. Ensuite, vous aurez une autre distribution de probabilité qui représente si les gens vont acheter deux ou quatre plaquettes de frein. Peut-être que ce sera 50-50, ou peut-être que ce sera 10 pour cent qui achètent deux et 90 pour cent qui achètent quatre. Le fait est que vous avez ces deux angles, et si vous voulez connaître la consommation totale réelle de plaquettes de frein, vous voulez multiplier la probabilité d’avoir un client qui se présente pour cette plaquette de frein et ensuite la distribution de probabilité d’acheter soit deux, soit quatre. Ainsi, vous devez avoir cette multiplication de ces deux quantités incertaines.

Ici, je suppose que les deux variables aléatoires sont indépendantes. Au fait, cette multiplication de variables aléatoires est connue en mathématiques sous le nom de convolution discrète. Vous pouvez voir sur la capture d’écran le tableau de bord généré par Envision. Dans les trois premières lignes, je fais ce calcul d’algèbre aléatoire, puis dans les lignes quatre, cinq et six, je mets ces choses en affichage sur la page web, dans le tableau de bord généré par le script. Je trace A1, B2, par exemple, tout comme dans une grille Excel. Les tableaux de bord Lokad sont organisés de manière similaire aux grilles Excel, avec des positions ayant des colonnes B, C, etc., et des lignes 1, 2, 3, 4, 5.

Vous pouvez voir que la convolution discrète, Z, a ce motif très bizarre, super pointu qui est en fait très couramment trouvé dans les supply chains lorsque les gens peuvent acheter des packs, des lots, ou des multiples. Dans ce genre de situation, il est généralement préférable de décomposer les sources des événements multiplicatifs associés au lot ou au pack. Vous devez avoir un langage de programmation qui a ces capacités disponibles à portée de main, en tant que citoyens de première classe. C’est exactement ce qu’est la programmation probabiliste, et c’est ainsi que nous l’avons mise en œuvre dans Envision.

Maintenant, parlons de la programmation différentiable. Je dois mettre un avertissement ici : je ne m’attends pas à ce que le public comprenne vraiment ce qui se passe, et je m’en excuse. Ce n’est pas que votre intelligence fait défaut ; c’est juste que ce sujet mérite une série entière de conférences. En fait, si vous regardez le plan des prochaines conférences, il y a une série entière consacrée à la programmation différentiable. Je vais aller super vite, et ça va être assez cryptique, donc je m’excuse d’avance.

Poursuivons avec le problème de supply chain qui nous intéresse ici, qui est la cannibalisation et la substitution. Ces problèmes sont très intéressants, et ils sont probablement là où la prévision des séries temporelles, qui est omniprésente, échoue de la manière la plus brutale. Pourquoi ? Parce que fréquemment, nous avons des clients ou des prospects qui viennent me demander si nous pouvons faire, par exemple, des prévisions à 13 semaines pour certains articles comme les sacs à dos. Je dirais oui, nous le pouvons, mais évidemment, si nous prenons un sac à dos et que nous voulons prévoir la demande pour ce produit, cela dépend massivement de ce que vous faites avec vos autres sacs à dos. Si vous n’avez qu’un seul sac à dos, alors peut-être que vous allez concentrer toute la demande de sacs à dos sur ce seul produit. Si vous introduisez 10 variantes différentes, évidemment il y aura des tonnes de cannibalisation. Vous n’allez pas multiplier le total des ventes par un facteur de 10 simplement parce que vous avez multiplié le nombre de références par 10. Donc évidemment, vous avez la cannibalisation et la substitution qui se produisent. Ces phénomènes sont prévalents dans les supply chains.

Comment analysez-vous la cannibalisation ou la substitution ? La façon dont nous le faisons chez Lokad, et je ne prétends pas que c’est la seule façon, mais c’est certainement une façon qui fonctionne, c’est généralement en regardant le graphique qui relie les clients et les produits. Pourquoi cela ? Parce que la cannibalisation se produit lorsque les produits sont en concurrence entre eux pour les mêmes clients. La cannibalisation est littéralement le reflet du fait que vous avez un client avec un besoin, mais qu’il a des préférences et va choisir un produit parmi l’ensemble des produits qui correspondent à son affinité, et n’en choisir qu’un seul. C’est l’essence même de la cannibalisation.

Si vous voulez analyser cela, vous devez analyser non pas les séries temporelles des ventes, car vous ne capturez pas cette information en premier lieu. Vous voulez analyser le graphique qui relie les transactions historiques entre les clients et les produits. Il se trouve que dans la plupart des entreprises, ces données sont facilement disponibles. Pour le e-commerce, c’est une évidence. Chaque unité que vous vendez, vous connaissez le client. En B2B, c’est la même chose. Même en B2C dans le commerce de détail, la plupart du temps, les chaînes de détail ont aujourd’hui des programmes de fidélité où elles connaissent un pourcentage à deux chiffres des clients qui se présentent avec leurs cartes, donc vous savez qui achète quoi. Pas pour 100% du trafic, mais vous n’en avez pas besoin. Si vous avez 10% et plus de vos transactions historiques où vous connaissez la paire de clients et de produits, c’est suffisant pour ce type d’analyse.

Dans ce petit extrait, je vais détailler une analyse d’affinité entre les clients et les produits. C’est littéralement l’étape fondamentale que vous devez prendre pour faire n’importe quel type d’analyse de cannibalisation. Regardons ce qui se passe dans ce code.

Des lignes une à cinq, c’est très banal ; je lis simplement un fichier plat qui contient un historique de transactions. Je lis simplement un fichier CSV qui a quatre colonnes : date, produit, client et quantité. Quelque chose de très basique. Je n’utilise même pas toutes ces colonnes, mais juste pour rendre l’exemple un peu plus concret. Dans l’historique des transactions, je suppose que les clients sont connus pour toutes ces transactions. Donc, c’est très banal ; je lis simplement des données à partir d’une table.

Ensuite, aux lignes sept et huit, je crée simplement la table pour les produits et la table pour les clients. Dans une configuration de production réelle, je ne créerais généralement pas ces tables ; je lirais ces tables à partir d’autres fichiers plats ailleurs. Je voulais garder l’exemple super simple, donc je suis juste en train d’extraire une table de produits à partir des produits que j’ai observés dans l’historique des transactions, et je fais la même chose pour les clients. Vous voyez, c’est juste une astuce pour le garder super simple.

Maintenant, les lignes 10, 11 et 12 impliquent des espaces latins, et cela va devenir un peu plus obscur. D’abord, à la ligne 10, je crée une table avec 64 lignes. La table ne contient rien ; elle est seulement définie par le fait qu’elle a 64 lignes, et c’est tout. C’est donc comme un espace réservé, une table banale avec beaucoup de lignes et pas de colonnes. Ce n’est pas très utile comme ça. Ensuite, “P” est essentiellement un produit cartésien, une opération mathématique avec toutes les paires. C’est une table où vous avez une ligne pour chaque ligne dans les produits et chaque ligne dans la table “L”. Donc, cette table “P” a 64 lignes de plus que la table des produits, et je fais la même chose pour les clients. Je gonfle simplement ces tables à travers cette dimension supplémentaire, qui est cette table “L”.

Ce sera mon support pour mes espaces latins, qui est exactement ce que je vais apprendre. Ce que je veux apprendre, c’est, pour chaque produit, un espace latin qui va être un vecteur de 64 valeurs, et pour chaque client, un espace latin de 64 valeurs également. Si je veux connaître l’affinité entre un client et un produit, je veux juste être capable de faire le produit scalaire entre les deux. Le produit scalaire est juste la multiplication terme à terme de tous les termes de ces deux vecteurs, puis vous faites la somme. Cela peut sembler très technique, mais c’est juste une multiplication terme à terme plus une somme - c’est le produit scalaire.

Ces espaces latins sont juste un jargon sophistiqué pour créer un espace avec des paramètres qui sont un peu inventés, où je veux juste apprendre. Toute la magie de la programmation différentiable se passe en seulement cinq lignes, des lignes 14 à 18. J’ai un mot-clé, “autodiff”, et “transactions”, qui dit que c’est une table d’intérêt, une table d’observations. Je vais traiter cette table ligne par ligne pour faire mon processus d’apprentissage. Dans ce bloc, je déclare un ensemble de paramètres. Les paramètres sont les choses que vous voulez apprendre, comme des nombres, mais vous ne connaissez pas encore les valeurs. Ces choses vont juste être initialisées aléatoirement, avec des nombres aléatoires.

J’introduis “X”, “X*”, et “Y”. Je ne vais pas plonger dans ce que fait exactement “X*” ; peut-être dans les questions. Je renvoie une expression qui est ma fonction de perte, et c’est la somme. L’idée du filtrage collaboratif ou de la décomposition de matrice est juste que vous voulez apprendre des espaces latins qui correspondent à tous vos bords dans votre graphe biparti. Je sais que c’est un peu technique, mais ce que nous faisons est littéralement très simple, en termes de supply chain. Nous apprenons l’affinité entre les produits et les clients.

Je sais que cela semble probablement super opaque, mais restez avec moi, et il y aura d’autres conférences où je vous donnerai une introduction plus réfléchie à cela. Tout est fait en cinq lignes, et c’est complètement remarquable. Quand je dis cinq lignes, je ne triche pas en disant : “Regardez, ce ne sont que cinq lignes, mais en réalité, je fais un appel à une bibliothèque tierce d’une complexité gigantesque où j’enterre toute l’intelligence.” Non, non, non. Ici, dans cet exemple, il n’y a littéralement pas de magie d’apprentissage automatique en dehors des deux mots-clés “autodiff” et “params”. “Autodiff” est utilisé pour définir un bloc où la programmation différentiable aura lieu, et d’ailleurs, c’est un bloc où je peux programmer n’importe quoi, donc littéralement, je peux injecter notre programme. Ensuite, j’ai “params” pour déclarer mes problèmes, et c’est tout. Donc, vous voyez, il n’y a pas de magie opaque en cours ; il n’y a pas une bibliothèque d’un million de lignes en arrière-plan qui fait tout le travail pour vous. Tout ce que vous devez savoir est littéralement sur cet écran, et c’est la différence entre un paradigme de programmation et une bibliothèque. Le paradigme de programmation vous donne accès à des capacités apparemment incroyablement sophistiquées, comme faire une analyse de cannibalisation avec juste quelques lignes de code, sans recourir à d’énormes bibliothèques tierces qui enveloppent la complexité. Il transcende le problème, le rendant beaucoup plus simple, de sorte que vous pouvez avoir quelque chose qui semble super compliqué résolu en seulement quelques lignes.

Maintenant, quelques mots sur le fonctionnement de la programmation différentiable. Il y a deux idées. L’une est la différentiation automatique. Pour ceux d’entre vous qui ont eu le luxe d’une formation en ingénierie, vous avez vu deux façons de calculer des dérivées. Il y a une dérivée symbolique, par exemple, si vous avez x au carré, vous faites la dérivée par x, et cela vous donne 2x. C’est une dérivée symbolique. Ensuite, vous avez la dérivée numérique, donc si vous avez une fonction f(x) que vous voulez différencier, ce sera f’(x) ≈ (f(x + ε) - f(x))/ε. C’est la dérivation numérique. Les deux ne conviennent pas pour ce que nous essayons de faire ici. La dérivation symbolique a des problèmes de complexité, car votre dérivée pourrait être un programme beaucoup plus complexe que le programme original. La dérivation numérique est numériquement instable, donc vous aurez beaucoup de problèmes de stabilité numérique.

La différentiation automatique est une idée fantastique datant des années 70 et redécouverte par le monde entier au cours de la dernière décennie. C’est l’idée que vous pouvez calculer la dérivée d’un programme informatique arbitraire, ce qui est stupéfiant. Encore plus stupéfiant, le programme qui est la dérivée a la même complexité computationnelle que le programme original, ce qui est étonnant. La programmation différentiable est juste une combinaison de différentiation automatique et de paramètres que vous voulez apprendre.

Alors, comment apprend-on ? Quand vous avez la dérivation, cela signifie que vous pouvez faire remonter les gradients, et avec la descente de gradient stochastique, vous pouvez faire de petits ajustements aux valeurs des paramètres. En ajustant ces paramètres, vous allez progressivement, à travers de nombreuses itérations de descente de gradient stochastique, converger vers des paramètres qui ont du sens et accomplir ce que vous voulez apprendre ou optimiser.

La programmation différentiable peut être utilisée pour des problèmes d’apprentissage, comme celui que j’illustre, où je veux apprendre l’affinité entre mes clients et mes produits. Elle peut également être utilisée pour des problèmes d’optimisation numérique, tels que l’optimisation de choses sous contraintes, et c’est un paradigme très évolutif. Comme vous pouvez le voir, cet aspect a été fait un citoyen de première classe dans Envision. Au fait, il y a encore quelques choses qui sont en cours en termes de syntaxe Envision, alors ne vous attendez pas exactement à ces choses encore ; nous sommes encore en train de peaufiner quelques aspects. Mais l’essence est là. Je ne vais pas discuter des détails des quelques choses qui sont encore en évolution.

Passons maintenant à un autre problème pertinent pour la préparation de votre configuration à la production. Typiquement, dans l’optimisation de la supply chain, vous faites face à des Heisenbugs. Qu’est-ce qu’un Heisenbug ? C’est un type de bug frustrant où une optimisation a lieu et produit des résultats absurdes. Par exemple, vous aviez un calcul par lots pour le réapprovisionnement des stocks pendant la nuit, et le matin, vous découvrez que certains de ces résultats étaient absurdes, causant des erreurs coûteuses. Vous ne voulez pas que le problème se reproduise, alors vous relancez votre processus. Cependant, lorsque vous relancez le processus, le problème a disparu. Vous ne pouvez pas reproduire le problème, et le Heisenbug ne se manifeste pas.

Cela peut sembler être un cas limite étrange, mais dans les premières années de Lokad, nous avons été confrontés à ces problèmes à plusieurs reprises. J’ai vu de nombreuses initiatives de supply chain, surtout de type data science, échouer à cause de Heisenbugs non résolus. Ils avaient des bugs qui se produisaient en production, essayaient de reproduire les problèmes localement mais n’y parvenaient pas, donc les problèmes n’ont jamais été résolus. Après quelques mois en mode panique, le projet entier était généralement abandonné en silence, et les gens revenaient à l’utilisation de tableurs Excel.

Si vous voulez obtenir une réplicabilité complète de votre logique, vous devez versionner le code et les données. La plupart des personnes dans l’audience qui sont des ingénieurs logiciels ou des data scientists peuvent être familiers avec l’idée de versionner le code. Cependant, vous voulez aussi versionner toutes les données de sorte que lorsque votre programme s’exécute, vous savez exactement quelle version du code et des données est utilisée. Vous ne pourrez peut-être pas reproduire le problème le lendemain parce que les données ont changé en raison de nouvelles transactions ou d’autres facteurs, donc les conditions qui ont déclenché le bug en premier lieu ne sont plus présentes.

Vous voulez vous assurer que votre environnement de programmation peut reproduire exactement la logique et les données telles qu’elles étaient en production à un moment précis. Cela nécessite une version complète de tout. Encore une fois, le langage de programmation et la pile de programmation doivent coopérer pour rendre cela possible. C’est réalisable sans que le paradigme de programmation soit un citoyen de première classe de votre pile, mais alors le Supply Chain Scientist doit être extrêmement prudent sur toutes les choses qu’ils font et la façon dont ils programment. Sinon, ils ne seront pas en mesure de reproduire leurs résultats. Cela met une pression immense sur les épaules des Supply Chain Scientists, qui sont déjà sous une pression significative de la supply chain elle-même. Vous ne voulez pas que ces professionnels aient à faire face à une complexité accidentelle, comme ne pas être en mesure de reproduire leurs propres résultats. Chez Lokad, nous appelons cela une “machine à remonter le temps” où vous pouvez tout reproduire à n’importe quel moment dans le passé.

Attention, il ne s’agit pas seulement de reproduire ce qui s’est passé la nuit dernière. Parfois, vous découvrez une erreur bien après le fait. Par exemple, si vous passez une commande d’achat à un fournisseur qui a un délai de trois mois, vous pouvez découvrir trois mois plus tard que la commande était absurde. Vous devez remonter trois mois en arrière jusqu’au moment où vous avez généré cette fausse commande d’achat pour comprendre quel était le problème. Il ne s’agit pas seulement de versionner les dernières heures de travail ; il s’agit littéralement d’avoir un historique complet de la dernière année d’exécution.

Une autre préoccupation est la montée des ransomwares et des cyberattaques sur les supply chains. Ces attaques sont massivement perturbatrices et peuvent être très coûteuses. Lors de la mise en œuvre de solutions basées sur des logiciels, vous devez vous demander si vous rendez votre entreprise et votre supply chain plus vulnérables aux cyberattaques et aux risques. De ce point de vue, Excel et Python ne sont pas idéaux. Ces composants sont programmables, ce qui signifie qu’ils peuvent comporter de nombreuses vulnérabilités de sécurité.

Si vous avez une équipe de data scientists ou de Supply Chain Scientists qui s’occupent des problèmes de supply chain, ils ne peuvent pas se permettre le processus minutieux et itératif de revue par les pairs du code qui est courant dans l’industrie du logiciel. Si un tarif change du jour au lendemain ou si un entrepôt est inondé, vous avez besoin d’une réponse rapide. Vous ne pouvez pas passer des semaines à produire des spécifications de code, des revues, etc. Le problème est que vous donnez des capacités de programmation à des personnes qui, par défaut, ont le potentiel de nuire accidentellement à l’entreprise. Cela peut être encore pire s’il y a un employé voyou intentionnel, mais même en mettant cela de côté, vous avez toujours le problème de quelqu’un qui expose accidentellement une partie interne des systèmes informatiques. N’oubliez pas, les systèmes d’optimisation de la supply chain, par définition, ont accès à une grande quantité de données à travers toute l’entreprise. Ces données ne sont pas seulement un atout, mais aussi une responsabilité.

Ce que vous voulez, c’est un paradigme de programmation qui favorise la programmation sécurisée. Vous voulez un langage de programmation où il y a des classes entières de choses que vous ne pouvez pas faire. Par exemple, pourquoi devriez-vous avoir un langage de programmation qui peut faire des appels système pour des fins d’optimisation de la supply chain ? Python peut faire des appels système, et Excel aussi. Mais pourquoi voudriez-vous un système programmable avec de telles capacités en premier lieu ? C’est comme acheter une arme pour se tirer une balle dans le pied.

Vous voulez quelque chose où des classes entières ou des fonctionnalités sont absentes parce que vous n’en avez pas besoin pour l’optimisation de la supply chain. Si ces fonctionnalités sont présentes, elles deviennent une responsabilité massive. Si vous introduisez des capacités programmables sans les outils qui imposent une programmation sécurisée par conception, vous augmentez le risque de cyberattaques et de ransomwares, ce qui aggrave les choses.

Bien sûr, il est toujours possible de compenser en doublant la taille de l’équipe de cybersécurité, mais c’est très coûteux et pas idéal face à des situations urgentes de supply chain. Vous devez agir rapidement et en toute sécurité, sans le temps pour les processus, les revues et les approbations habituels. Vous voulez aussi une programmation sécurisée qui élimine les problèmes banals comme les exceptions de référence nulle, les erreurs de mémoire, les boucles hors de un et les effets secondaires.

En conclusion, l’outillage compte. Il y a un adage : “N’apportez pas une épée à un combat de pistolets.” Vous avez besoin des outils et des paradigmes de programmation appropriés, pas seulement de ceux que vous avez appris à l’université. Vous avez besoin de quelque chose de professionnel et de niveau production pour répondre aux besoins de votre supply chain. Bien que vous puissiez obtenir certains résultats avec des outils médiocres, ce ne sera pas génial. Un musicien fantastique peut faire de la musique avec juste une cuillère, mais avec un instrument approprié, il peut faire beaucoup mieux.

Maintenant, passons aux questions. Veuillez noter qu’il y a un délai d’environ 20 secondes, donc il y a une certaine latence dans le flux entre la vidéo que vous voyez et moi qui lis vos questions.

Question : Qu’en est-il de la programmation dynamique en termes de recherche opérationnelle ?

La programmation dynamique, malgré son nom, n’est pas un paradigme de programmation. C’est plutôt une technique algorithmique. L’idée est que si vous voulez effectuer une tâche algorithmique ou résoudre un certain problème, vous répéterez très fréquemment la même sous-opération. La programmation dynamique est un cas spécifique du compromis espace-temps dont j’ai parlé plus tôt, où vous investissez un peu plus en mémoire pour gagner du temps sur le côté calcul. C’était l’une des premières techniques algorithmiques, datant des années 60 et 70. C’est une bonne technique, mais le nom est un peu malheureux car il n’y a rien de vraiment dynamique à ce sujet, et ce n’est pas vraiment de la programmation. Il s’agit plutôt de la conception d’algorithmes. Donc, pour moi, malgré le nom, cela ne se qualifie pas comme un paradigme de programmation ; c’est plutôt une technique algorithmique spécifique.

Question : Johannes, pourriez-vous gentiment fournir quelques livres de référence que tout bon ingénieur en supply chain devrait avoir ? Malheureusement, je suis nouveau dans le domaine, et mon focus actuel est la data science et l’ingénierie des systèmes.

J’ai une opinion très mitigée sur la littérature existante. Dans ma première conférence, j’ai présenté deux livres que je considère comme le sommet des études académiques concernant la supply chain. Si vous voulez lire deux livres, vous pouvez lire ces livres. Cependant, j’ai un problème constant avec les livres que j’ai lus jusqu’à présent. En gros, vous avez des gens qui présentent des collections de recettes numériques pour des supply chains idéalisées, et je crois que ces livres n’abordent pas la supply chain sous le bon angle, et ils manquent complètement le point que c’est un problème épineux. Il y a un vaste corpus de littérature qui est très technique, avec des équations, des algorithmes, des théorèmes et des preuves, mais je crois qu’il manque complètement le point.

Ensuite, vous avez un autre style de livres sur la gestion de la supply chain, qui sont plus dans le style consultant. Vous pouvez facilement reconnaître ces livres parce qu’ils utilisent des analogies sportives toutes les deux pages. Ces livres ont toutes sortes de diagrammes simplistes, comme des variantes 2x2 des diagrammes SWOT (Strengths, Weaknesses, Opportunities, Threats), que je considère comme des moyens de raisonnement de faible qualité. Le problème avec ces livres est qu’ils ont tendance à mieux comprendre que la supply chain est une entreprise épineuse. Ils comprennent beaucoup mieux que c’est un jeu joué par des gens, où toutes sortes de choses bizarres peuvent se produire, et vous pouvez être intelligent de différentes manières. Je leur donne du crédit pour cela. Le problème avec ces livres, généralement écrits par des consultants ou des professeurs d’écoles de management, est qu’ils ne sont pas très concrets. Le message se résume à “soyez un meilleur leader”, “soyez plus intelligent”, “ayez plus d’énergie”, et pour moi, ce n’est pas concret. Il ne vous donne pas d’éléments que vous pouvez transformer en quelque chose de très précieux, comme le logiciel peut le faire.

Donc, je reviens à la première conférence : lisez les deux livres si vous le souhaitez, mais je ne suis pas sûr que ce sera du temps bien dépensé. Il est bon de savoir ce que les gens ont écrit. Du côté consultant de la littérature, mon préféré est probablement le travail de Katana, que je n’ai pas listé dans la première conférence. Tout n’est pas mauvais ; certaines personnes ont plus de talent, même si elles sont plus consultant-ish. Vous pouvez consulter le travail de Katana ; il a un livre sur les supply chains dynamiques. Je vais lister le livre dans les références.

Question : Comment utilisez-vous la parallélisation lorsque vous traitez des décisions de cannibalisation ou d’assortiment, où le problème n’est pas facilement parallélisable ?

Pourquoi n’est-il pas facilement parallélisable ? La descente de gradient stochastique est assez facile à paralléliser. Vous avez des étapes de gradient stochastique qui peuvent être prises dans des ordres aléatoires, et vous pouvez avoir plusieurs étapes en même temps. Donc, je crois que tout ce qui est piloté par la descente de gradient stochastique est assez facile à paralléliser.

Lorsqu’on traite la cannibalisation, ce qui est plus difficile est de traiter un autre type de parallélisation, qui est ce qui vient en premier. Si je mets ce produit en premier, alors je fais une prévision, mais ensuite je prends un autre produit, cela modifie le paysage. La réponse est que vous voulez avoir un moyen d’aborder tout le paysage de front. Vous ne dites pas : “D’abord, j’introduis ce produit et je fais la prévision ; j’introduis un autre produit et je refais la prévision, en modifiant la première”. Vous le faites de manière frontale, toutes ces choses en même temps, en même temps. Vous avez besoin de plus de paradigmes de programmation. Les paradigmes de programmation que j’ai introduits aujourd’hui peuvent aller très loin pour cela.

En ce qui concerne les décisions d’assortiment, ce type de problèmes ne présente pas de grandes difficultés pour la parallélisation. La même chose s’applique si vous avez un réseau de vente au détail mondial, et que vous voulez optimiser l’assortiment pour tous vos magasins. Vous pouvez avoir des calculs qui se produisent pour tous les magasins en parallèle. Vous ne voulez pas le faire en séquence, où vous optimisez l’assortiment pour un magasin puis passez au magasin suivant. C’est la mauvaise façon de faire, mais vous pouvez optimiser le réseau en parallèle, propager toutes les informations, puis répéter. Il existe toutes sortes de techniques, et les outils peuvent grandement vous aider à le faire de manière beaucoup plus facile.

Question : Utilisez-vous une approche de base de données graphique ?

Non, pas dans le sens technique et canonique. Il existe de nombreuses bases de données graphiques sur le marché qui sont très intéressantes. Ce que nous utilisons en interne chez Lokad, c’est une intégration verticale complète à travers une pile de compilateurs unifiée et monolithique pour éliminer entièrement tous les éléments traditionnels que vous trouveriez dans une pile classique. C’est ainsi que nous obtenons de très bonnes performances, en termes de performances de calcul, très proches du métal. Non pas parce que nous sommes des codeurs fantastiquement intelligents, mais simplement parce que nous avons éliminé pratiquement toutes les couches qui existent traditionnellement. Lokad n’utilise littéralement aucune base de données. Nous avons un compilateur qui s’occupe de tout, jusqu’à l’organisation des structures de données pour la persistance. C’est un peu étrange, mais c’est beaucoup plus efficace de le faire de cette façon, et de cette façon, vous jouez beaucoup plus agréablement avec le fait que vous compilez un script vers une flotte de machines sur le cloud. Votre plateforme cible, en termes de matériel, n’est pas une machine ; c’est une flotte de machines.

Question : Quelle est votre opinion sur Power BI, qui exécute également des codes Python et des algorithmes associés comme la descente de gradient, le greedy, etc. ?

Le problème que j’ai avec tout ce qui est lié à l’intelligence d’affaires, Power BI en étant un, c’est qu’il a un paradigme que je pense être inadéquat pour la supply chain. Vous voyez tous les problèmes comme un hypercube, où vous avez des dimensions que vous ne faites que découper et désosser. Au cœur, vous avez un problème d’expressivité, qui est très limitant. Lorsque vous finissez par utiliser Power BI avec Python au milieu, vous avez besoin de Python parce que l’expressivité liée à l’hypercube est très pauvre. Pour retrouver de l’expressivité, vous ajoutez Python au milieu. Cependant, souvenez-vous de ce que j’ai dit dans la question précédente à propos de ces couches : la malédiction du logiciel d’entreprise moderne est que vous avez trop de couches. Chaque couche que vous ajoutez va introduire des inefficacités et des bugs. Si vous utilisez Power BI plus Python, vous allez avoir beaucoup trop de couches. Donc, vous avez Power BI qui se situe au-dessus d’autres systèmes, ce qui signifie que vous avez déjà plusieurs systèmes avant Power BI. Ensuite, vous avez Power BI en haut, et au-dessus de Power BI, vous avez Python. Mais est-ce que Python agit seul ? Non, il y a de fortes chances que vous utilisiez des bibliothèques Python, comme Pandas ou NumPy. Donc, vous avez des couches en Python qui vont s’empiler, et vous finissez par avoir des dizaines de couches. Vous pouvez avoir des bugs dans n’importe laquelle de ces couches, donc la situation va être assez cauchemardesque.

Je ne crois pas en ces solutions où vous finissez par avoir un nombre massif de piles. Il y a cette blague qu’en C++, vous pouvez toujours résoudre n’importe quel problème en ajoutant une couche d’indirection supplémentaire, y compris le problème d’avoir trop de couches d’indirection. Évidemment, cette affirmation est un peu absurde, mais je suis profondément en désaccord avec l’approche où les gens ont un produit avec une conception de base inadéquate, et au lieu de s’attaquer frontalement au problème, ils finissent par ajouter des choses par-dessus alors que les fondations sont fragiles. Ce n’est pas la façon de faire, et vous allez avoir une faible productivité, des batailles constantes avec des bugs que vous ne résoudrez jamais, et ensuite, en termes de maintenabilité, c’est juste une recette pour un cauchemar.

Question : Comment les résultats d’une analyse de filtrage collaboratif peuvent-ils être intégrés dans l’algorithme de prédiction de la demande pour chaque produit, comme les sacs à dos, par exemple ?

Je suis désolé, mais j’aborderai ce sujet dans la prochaine conférence. La réponse courte est que vous ne voulez pas intégrer cela dans un algorithme de prédiction existant. Vous voulez avoir quelque chose qui est beaucoup plus nativement intégré. Vous ne faites pas cela et ensuite vous revenez à vos anciennes méthodes de prévision ; au lieu de cela, vous abandonnez simplement l’ancienne façon de faire la prévision et faites quelque chose de radicalement différent qui exploite cela. Mais j’en discuterai dans une conférence ultérieure. Ce serait trop pour aujourd’hui.

Je suppose que c’est tout pour cette conférence. Merci beaucoup à tous d’avoir assisté. La prochaine conférence aura lieu le mercredi 6 janvier, même heure, même jour de la semaine. Je vais prendre des vacances de Noël, alors je souhaite à tous un joyeux Noël et une bonne année. Nous continuerons notre série de conférences l’année prochaine. Merci beaucoup.