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 par tableau
28:08 Miscibilité matérielle
35:38 Programmation probabiliste
40:53 Programmation différentiable
55:12 Versionnage code+données
01:00:01 Programmation sécurisée
01:05:37 En conclusion, les outils comptent aussi en Supply Chain
01:06:40 Prochaine conférence et questions du public
Description
Alors que la théorie de la Supply Chain dominante a du mal à s’imposer dans les entreprises en général, un outil – à savoir Microsoft Excel – a rencontré un succès opérationnel considérable. La réimplémentation des recettes numériques de la théorie de la Supply Chain dominante via les feuilles de calcul est triviale, pourtant, ce n’est pas ce qui s’est passé en pratique malgré la prise de conscience de la théorie. Nous démontrons que les feuilles de calcul ont gagné en adoptant des paradigmes de programmation qui se sont avérés supérieurs pour produire des résultats Supply Chain.
Transcription intégrale
Bonjour à tous, bienvenue dans cette série de conférences Supply Chain. Je suis Joannes Vermorel, et aujourd’hui je vais vous présenter ma quatrième conférence : Paradigmes de programmation pour Supply Chain.
Donc, quand on me demande : “Monsieur Vermorel, quelles sont selon vous les thématiques les plus intéressantes en matière de connaissances Supply Chain ?” l’une de mes réponses principales est généralement les paradigmes de programmation. Et puis, pas trop souvent, mais suffisamment fréquemment, la réaction de la personne à qui je m’adresse est : “Paradigmes de programmation, Monsieur Vermorel ? De quoi diable parlez-vous ? En quoi cela est-il le moins du monde pertinent pour la tâche à accomplir ?” Et ces réactions, certes peu fréquentes, me rappellent invariablement cette citation absolument incroyable de Robert A. Heinlein, considéré comme le doyen des auteurs de science-fiction.
Heinlein propose une citation fantastique sur l’homme compétent, qui souligne l’importance de la compétence dans divers domaines, notamment dans la Supply Chain où nous sommes confrontés à des problèmes épineux. Ces problèmes sont presque aussi difficiles que la vie elle-même, et je pense qu’il vaut vraiment la peine de consacrer du temps à 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 Supply Chain sont épineux. Quiconque évoque des solutions optimales manque le sujet ; il n’existe rien d’approchant l’optimalité. Dans la deuxième conférence, j’ai présenté la la Supply Chain Quantitative, une vision reposant sur cinq exigences clés pour atteindre l’excellence en gestion de la Supply Chain. Ces exigences ne suffisent pas à elles seules, mais elles ne peuvent être contournées si vous voulez atteindre l’excellence.
Dans la troisième conférence, j’ai abordé la livraison d’un produit logiciel dans le contexte de l’optimisation de la Supply Chain. J’ai défendu l’idée que l’optimisation de la Supply Chain requiert qu’un produit logiciel soit traité de manière appropriée dans une logique capitaliste, mais vous ne pouvez pas trouver un tel produit sur le marché. Il y a trop de diversité, et les défis auxquels nous sommes confrontés dépassent de loin les technologies dont nous disposons actuellement. Donc, il s’agira, par nécessité, de quelque chose de complètement sur mesure. Ainsi, s’il s’agit d’un produit logiciel qui sera sur mesure pour l’entreprise ou la Supply Chain concernée, il faut se poser la question des outils adéquats pour délivrer réellement ce produit. Cela m’amène au thème 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 programmatiques pour gérer l’optimisation du problème, sans confondre avec la partie gestion. Ce que nous avons vu, qui était le thème de ma conférence précédente, c’est que Microsoft Excel a été le grand gagnant jusqu’ici. Des très petites aux très grandes entreprises, il est omniprésent, utilisé partout. Même dans des entreprises ayant investi des millions de dollars dans des systèmes ultra-performants, Excel règne toujours, et pourquoi ? Parce qu’il possède les bonnes propriétés de programmation. Il est très expressif, agile, accessible et maintenable. Cependant, Excel n’est pas l’aboutissement final. Je suis fermement convaincu que nous pouvons faire bien plus, mais nous devons disposer des bons outils, de la bonne mentalité, d’idées innovantes et des bons paradigmes de programmation.
Les paradigmes de programmation peuvent sembler excessivement obscurs pour l’audience, mais il s’agit en réalité d’un domaine d’étude qui a fait l’objet d’une recherche intensive au cours des cinq dernières décennies. Un travail immense a été accompli dans ce domaine. Il n’est pas largement connu du grand public, mais il existe des bibliothèques entières remplies de travaux de haute qualité réalisés par de nombreuses personnes. Ainsi, aujourd’hui, je vais vous présenter une série de sept paradigmes adoptés par Lokad. Nous n’avons inventé aucune de ces idées ; nous les avons reprises auprès de personnes qui les avaient inventées avant nous. Tous ces paradigmes ont été implémentés dans le produit logiciel de Lokad, et après près d’une décennie d’exploitation de Lokad en production, en tirant parti de ces paradigmes, je pense qu’ils ont été absolument essentiels à notre succès opérationnel jusqu’à présent.
Passons à cette liste avec l’analyse statique. Le problème ici est la complexité. Comment gérer la complexité dans la Supply Chain ? Vous allez être confronté à des systèmes d’entreprise possédant des centaines de tables, chacune avec des dizaines de champs. Si vous envisagez un problème aussi simple que le reapprovisionnement des stocks dans un entrepôt, il y a tellement de choses à prendre en compte. Vous pouvez avoir des quantités minimales de commande, des remises de prix, des prévisions de demande, des prévisions de délais d’approvisionnement, et toutes sortes de retours. Vous pouvez être confronté à des limitations d’espace sur les étagères, à des capacités de réception limitées et à des dates d’expiration qui rendent certains de vos lots obsolètes. Ainsi, vous vous retrouvez avec une multitude d’éléments à considérer. Dans la Supply Chain, l’idée du “move fast and break things” n’est tout simplement pas la bonne approche. Si vous commandez par inadvertance pour un million de dollars de marchandises dont vous n’avez absolument pas besoin, c’est une erreur très coûteuse. Vous ne pouvez pas avoir un logiciel pilotant votre Supply Chain, prenant des décisions de routine, et qu’en cas de bug, cela vous coûte des millions. Nous devons disposer de quelque chose qui assure un très haut degré de correction par conception. Nous ne voulons pas découvrir les bugs en production. Cela est très différent d’un logiciel ordinaire où un crash n’est pas dramatique.
En ce qui concerne l’optimisation de la Supply Chain, ce n’est pas un problème ordinaire. Si vous venez de passer une commande massive et incorrecte à un fournisseur, vous ne pouvez pas simplement l’appeler une semaine plus tard pour dire, “Oh, c’était une erreur, non, oubliez, nous n’avons jamais commandé cela.” Ces erreurs vont coûter très cher. L’analyse statique porte ce nom parce qu’elle consiste à analyser un programme sans l’exécuter. L’idée est que vous disposez d’un programme écrit avec des instructions, des mots-clés, et tout le reste, et qu’en n’exécutant même pas ce programme, vous pouvez déjà déterminer si celui-ci présente des problèmes qui auraient très certainement un impact négatif sur votre production, en particulier sur la production Supply Chain. La réponse est oui. Ces techniques existent et sont mises en œuvre, et elles sont extrêmement précieuses.
Pour donner un exemple, vous pouvez voir une capture d’écran d’Envision à l’écran. Envision est un langage de programmation spécifique au domaine qui a été développé pendant presque une décennie par Lokad et est dédié à la predictive optimization de 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 importante logique pour le reapprovisionnement des stocks dans un entrepôt, et que vous introduisez quelques variables économiques, comme des remises de prix, à travers une analyse logique du programme, vous constatez que ces remises de prix n’ont aucun lien avec les résultats finaux renvoyés par le programme, à savoir les quantités à reconstituer. Ici, vous avez un problème évident. Vous avez introduit une variable importante, les remises de prix, et celles-ci n’ont logiquement aucune influence sur les résultats finaux. Ainsi, nous avons ici un problème qui peut être détecté grâce à l’analyse statique. C’est un problème flagrant, car si nous introduisons dans le code des variables qui n’ont aucun impact sur la sortie du programme, alors elles ne servent absolument à rien. Dans ce cas, nous sommes confrontés à deux options : soit ces variables constituent effectivement du code mort, et le programme ne devrait pas compiler (il faudrait simplement s’en débarrasser pour réduire la complexité et éviter d’empiler une complexité accidentelle), soit c’était une erreur authentique et il existait une variable économique importante qui aurait dû être intégrée à votre calcul, mais vous l’avez négligée par distraction ou pour une autre raison.
L’analyse statique est absolument fondamentale pour atteindre un degré de correction par conception. Il s’agit de corriger les problèmes au moment de la compilation, lors de l’écriture du code, et ce, même avant de traiter les données. Si des problèmes apparaissent lors de l’exécution, il y a de fortes chances qu’ils surviennent durant la nuit, lorsque le traitement nocturne gère le reapprovisionnement des stocks. Le programme est susceptible de s’exécuter à des heures inhabituelles, lorsque personne ne le surveille, vous ne voulez donc pas qu’il plante en l’absence de quelqu’un pour le constater. Il devrait planter au moment où les gens écrivent effectivement le code.
L’analyse statique a de nombreux objectifs. Par exemple, chez Lokad, nous l’utilisons pour l’édition WYSIWYG des tableaux de bord. WYSIWYG signifie “ce que vous voyez est ce que vous obtenez”. 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 souhaitez pouvoir le faire de manière visuelle, et non modifier le style de votre tableau de bord via le code, car cela est très fastidieux. Tous les paramètres que vous avez mis en place seront réinjectés dans le code lui-même, et cela se fait grâce à l’analyse statique.
Un autre aspect chez Lokad, qui peut ne pas être d’une telle importance pour la Supply Chain dans son ensemble mais certainement critique pour mener à bien le projet, était la gestion d’un langage de programmation appelé Envision que nous développons. Nous savions dès le premier jour, il y a presque une décennie, que des erreurs allaient être commises. Nous n’avions pas de boule de cristal pour avoir la vision parfaite dès le départ. La question était : comment pouvons-nous nous assurer de pouvoir corriger au mieux ces erreurs de conception dans le langage de programmation lui-même ? Ici, Python m’a servi d’avertissement.
Python, qui n’est pas un langage nouveau, a été lancé pour la première fois en 1991, il y a près de 30 ans. La migration de Python 2 vers Python 3 a pris presque une décennie à toute la communauté, et ce fut un processus cauchemardesque, très pénible pour les entreprises impliquées dans cette migration. Mon constat était que le langage lui-même ne disposait pas de suffisamment de constructions. Il n’a pas été conçu de manière à permettre la migration de programmes d’une version à une autre de façon entièrement automatisée. En réalité, cela était extrêmement difficile à réaliser, et c’est parce que Python n’a pas été conçu avec l’analyse statique à l’esprit. Lorsque vous disposez d’un langage de programmation pour la Supply Chain, vous voulez vraiment qu’il soit d’une qualité excellente en termes d’analyse statique, car vos programmes seront durables. Les Supply Chain n’ont pas le luxe de dire, “Attendez trois mois, nous sommes en train de réécrire le code. Patiencez, la cavalerie arrive.” C’est littéralement comparable à réparer un train pendant qu’il roule à pleine vitesse sur les rails, et devoir réparer le moteur pendant que le train est en marche. C’est à cela que ressemble la réparation d’éléments de la Supply Chain qui sont réellement en production. Vous n’avez pas le luxe de mettre le système en pause ; il ne se met jamais en pause.
Le deuxième paradigme est celui de la programmation par tableau. Nous voulons maîtriser la complexité, car c’est un thème récurrent majeur dans la Supply Chain. Nous souhaitons disposer d’une logique qui évite certaines catégories d’erreurs de programmation. Par exemple, dès que vous avez des boucles ou des branches écrites explicitement par les programmeurs, vous vous exposez à des classes entières de problèmes très difficiles. Cela devient extrêmement compliqué lorsque l’on peut simplement écrire des boucles arbitraires pour garantir 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, imaginons que vous ayez une enseigne de distribution. À minuit, ils auront complètement consolidé toutes les ventes de l’ensemble du réseau, et les données seront centralisées et transmises à un système d’optimisation. Ce système disposera exactement d’une fenêtre de 60 minutes pour effectuer les prévisions, l’optimisation de stocks, et les décisions de réaffectation pour chaque magasin du réseau. Une fois terminé, 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 seront chargés, peut-être à 5h00, et à 9h00, les magasins ouvriront avec les marchandises déjà reçues et placées sur les étagères.
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 l’ensemble de la supply chain. Vous ne voulez pas vous retrouver dans une situation où vous découvrez en production combien de temps prennent les opérations. Si vous avez des boucles où les gens peuvent décider du nombre d’itérations à effectuer, il est très difficile d’obtenir une preuve de la durée de votre calcul. Gardez à l’esprit que nous parlons de l’optimization de la supply chain. Vous n’avez pas le luxe de procéder à des revues par les pairs et de tout vérifier. 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.
Donc, la programmation sur tableaux repose sur l’idée que vous pouvez opérer directement sur des tableaux. Si l’on regarde l’extrait de code que nous avons ici, il s’agit de code Envision, le DSL de Lokad. Pour comprendre ce qui se passe, vous devez comprendre que lorsque j’écris “orders.amounts”, cela correspond à une variable et “orders” est en réalité une table au sens d’une table relationnelle, comme une table de votre base de données. Par exemple, ici à la première ligne, “amounts” serait une colonne de la table. À la ligne un, ce que je fais, c’est littéralement dire que pour chaque ligne de la table orders, je vais simplement prendre “quantity”, qui est une colonne, la multiplier par “price”, pour obtenir une troisième colonne générée dynamiquement, qui est “amount”.
D’ailleurs, le terme moderne pour la programmation sur tableaux est aujourd’hui également connu sous le nom de programmation sur data frames. Ce domaine d’étude est assez ancien ; il remonte à trois ou quatre décennies, voire même quatre ou cinq. Il a toujours été connu comme la programmation sur tableaux, même si de nos jours les gens sont généralement plus familiers avec l’idée des data frames. À la ligne deux, ce que nous faisons, c’est appliquer un filtre, à la manière du SQL. Nous filtrons les dates, et il se trouve que la table orders contient une date. Elle sera filtrée, et je spécifie “date qui est supérieure à aujourd’hui moins 365”, autrement dit en jours. Nous conservons les données de l’année dernière, puis nous écrivons “products.soldLastYear = SUM(orders.amount)”.
Or, la chose intéressante est que nous avons ce que l’on appelle une jointure naturelle entre products et orders. Pourquoi ? Parce que chaque ligne de commande est associée à un seul produit, et qu’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 simplement la somme de ce qui se passe au niveau des orders”, et c’est exactement ce qui est fait à la ligne neuf. Vous remarquerez peut-être que la syntaxe est très épurée ; il n’y a pas beaucoup d’accidentels ou de subtilités techniques. Je soutiendrais que ce code est presque entièrement dépourvu d’accidentels en ce qui concerne la programmation sur data frames. Ensuite, aux lignes 10, 11 et 12, nous affichons simplement une table 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 sur tableaux pour les supply chains. Tout d’abord, elle élimine des catégories entières de problèmes. Vous n’aurez pas d’erreurs de décalage d’index dans vos tableaux. Il sera bien 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 qui sera exécuté non pas sur une seule machine locale, mais directement sur une flotte de machines qui vivent dans le cloud computing, et d’ailleurs, c’est exactement ce qui se fait chez Lokad. Cette parallélisation automatique est d’un intérêt extrêmement majeur.
Vous voyez, le fonctionnement est le suivant : lorsque vous pratiquez l’optimization de la supply chain, vos habitudes de consommation en termes de matériel informatique sont extrêmement intermittentes. Si je reviens à l’exemple que je donnais concernant la fenêtre de 60 minutes pour les réseaux de distribution lors du réapprovisionnement des magasins, cela signifie qu’il y a une heure par jour où vous avez besoin de puissance de calcul pour effectuer tous vos calculs, mais pendant les 23 heures restantes, ce n’est pas le cas. Ce que vous souhaitez donc, c’est un programme qui, au moment de son exécution, se répartira sur de nombreuses machines et, une fois terminé, libérera toutes ces machines pour que d’autres calculs puissent être effectués. L’alternative serait de disposer de nombreuses machines que vous louez et pour lesquelles vous 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 puissiez vous répartir sur de nombreuses machines de manière rapide et prévisible, puis libérer la puissance de traitement, nécessite le cloud computing dans un environnement multi-locataire ainsi qu’une série d’autres éléments que Lokad met en œuvre. Mais avant tout, elle requiert la coopération du langage de programmation lui-même. C’est tout simplement impossible 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 intelligente et pertinente. Il ne s’agit pas 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 catégories entières de bugs potentiels dans votre supply chain. C’est révolutionnaire.
La programmation sur tableaux existe déjà dans de nombreux aspects, comme dans NumPy et pandas en Python, qui sont si populaires auprès du segment data scientist de l’audience. Mais la question que je vous pose est la suivante : si c’est si important et utile, pourquoi ces éléments ne sont-ils pas considérés comme 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 concerne uniquement la programmation sur tableaux sur une seule machine, mais pourquoi ne pas faire de la programmation sur tableaux sur une flotte de machines ? C’est bien plus puissant et bien plus adapté lorsque vous disposez d’un cloud computing avec une capacité matérielle accessible.
Alors, quel sera le goulot d’étranglement dans l’optimization de la supply chain ? Il y a ce dicton de Goldratt qui affirme : “Toute amélioration apportée en dehors du goulot d’étranglement dans une supply chain n’est qu’une illusion”, et je suis tout à fait d’accord avec cette affirmation. En réalité, lorsque nous souhaitons faire de l’optimization de la supply chain, le goulot d’étranglement sera les personnes, et plus précisément, les Supply Chain Scientists qui, malheureusement pour Lokad et mes clients, ne poussent pas sur les arbres.
Le goulot d’étranglement, ce sont les Supply Chain Scientists, les personnes capables de concevoir des 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 pouvant ê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 voyais tout le monde au labo pratiquait littéralement la data science. La plupart des gens écrivaient du code pour une sorte de modèle avancé de deep learning, ils appuyaient sur entrée puis 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, le labo entier é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 basse.
Lorsque j’ai fondé ma propre entreprise, j’avais en tête que je ne voulais pas finir par payer une armée de personnes ultra-intelligentes qui passent la majeure partie de leur journée à siroter du café, attendant que leurs programmes s’exécutent afin d’obtenir des résultats et de passer à autre chose. En théorie, ils pourraient paralléliser de nombreuses tâches simultanément et réaliser des expériences, mais en pratique, je n’ai jamais vraiment observé cela. Intellectuellement, lorsque vous cherchez à résoudre un problème, vous souhaitez tester votre hypothèse, et vous avez besoin du résultat pour aller de l’avant. Il est très difficile de mener de front des tâches hautement techniques et de poursuivre plusieurs pistes intellectuelles simultanément.
Cependant, il y avait une lueur d’espoir. Les data scientists, et désormais les Supply Chain Scientists chez Lokad, ne finissent pas par écrire mille lignes de code pour ensuite dire “please run”. Ils ajoutent généralement deux lignes à un script de mille lignes, puis ils demandent l’exécution du script. Ce script s’exécute sur exactement les mêmes données qu’ils viennent d’exécuter quelques minutes auparavant. La logique est presque identique, à l’exception de ces deux lignes. Alors, comment traiter des téraoctets de données en quelques secondes au lieu de plusieurs minutes ? La réponse est que, lors de l’exécution précédente du script, vous avez enregistré toutes les étapes intermédiaires du calcul et les avez stockées (généralement sur des disques SSD), qui sont très bon marché, rapides et pratiques.
La prochaine fois que vous exécuterez votre programme, le système remarquera que le script est presque identique. Il effectuera une comparaison (diff) et constatera qu’en termes de graphe de calcul, il est presque identique, à l’exception de quelques différences. En ce qui concerne les données, il est généralement identique à 100 %. Parfois, il y a quelques modifications, mais presque rien. Le système diagnostiquera automatiquement que vous n’avez que peu de calculs à exécuter, de sorte que vous pouvez obtenir 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 obtenir le résultat à celles qui appuient sur entrée et, 5 ou 10 secondes plus tard, disposent du résultat et peuvent passer à autre chose.
Je parle de quelque chose qui peut sembler super obscur, mais en pratique, il s’agit d’un élément qui a un impact de 10 fois sur la productivité. C’est énorme. Ce que nous faisons ici, c’est utiliser une astuce ingénieuse que Lokad n’a pas inventée. Nous substituons une ressource brute de calcul, à savoir la puissance de calcul, par une autre, qui est la mémoire et le stockage. Nous disposons des ressources informatiques fondamentales : calcul, mémoire (volatile ou persistante) et bande passante. Ce sont les ressources fondamentales pour lesquelles vous payez lorsque vous achetez des ressources sur une plateforme de cloud computing. Vous pouvez en réalité substituer une ressource par une autre, et l’objectif est d’obtenir le meilleur rapport qualité-prix.
Quand on dit que vous devriez utiliser le in-memory computing, je dirais que c’est absurde. Si vous dites in-memory computing, cela signifie que vous mettez l’accent sur une ressource au détriment des autres. Mais non, il y a des compromis, et l’intéressant est que vous pouvez disposer d’un langage de programmation et d’un environnement qui facilite la mise en œuvre de ces compromis et de ces perspectives. Dans un langage de programmation généraliste classique, c’est possible, mais vous devez le faire manuellement. Cela signifie que la personne qui le réalise doit être un ingénieur logiciel professionnel. Un Supply Chain Scientist ne va pas exécuter ces opérations de bas niveau avec les ressources informatiques fondamentales de votre plateforme. Cela doit être intégré au niveau même du langage de programmation.
Maintenant, parlons de la programmation probabiliste. Dans la deuxième conférence où j’ai présenté la vision pour la Supply Chain Quantitative, ma première exigence était que nous devions examiner tous les futurs possibles. La réponse technique à cette exigence est probabilistic forecasting. Vous souhaitez traiter des futurs pour lesquels vous disposez de probabilités. Tous les futurs sont possibles, mais ils ne sont pas tous également probables. Vous avez besoin d’une algèbre vous permettant d’effectuer des calculs avec incertitude. L’une de mes grandes critiques envers Excel est qu’il est extrêmement difficile d’y représenter l’incertitude, que ce soit avec Excel ou toute autre version moderne basée sur le cloud computing. Dans une feuille de calcul, il est très difficile de représenter l’incertitude car il vous faut quelque chose de mieux que des nombres.
Dans ce petit extrait, j’illustre l’algèbre des variables aléatoires, qui est une fonctionnalité native d’Envision. À la ligne un, je génère une distribution de Poisson discrète, avec une moyenne de 2, et je la stocke dans la variable X. Ensuite, je fais de même pour une autre distribution de Poisson, Y. Puis, je calcule Z comme la multiplication de X par Y. Cette opération, la multiplication de variables aléatoires, peut sembler très étrange. Pourquoi auriez-vous même besoin de ce type d’opération d’un point de vue supply chain ? Laissez-moi vous donner un exemple.
Disons que vous êtes dans le secteur de l’après-vente 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. La question est donc que si vous souhaitez réaliser une prévision, vous pourriez vouloir 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 donnera 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 % achetant deux et 90 % achetant quatre. Le fait est que vous avez ces deux angles, et si vous voulez connaître la consommation totale réelle des plaquettes de frein, vous devez multiplier la probabilité qu’un client se présente pour cet article par la distribution de probabilité d’achat de deux ou de quatre. Ainsi, vous devez effectuer la multiplication de ces deux quantités incertaines.
Ici, je suppose que les deux variables aléatoires sont indépendantes. D’ailleurs, 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, j’effectue ce calcul d’algèbre aléatoire, puis aux lignes quatre, cinq et six, j’affiche ces éléments sur la page web, dans le tableau de bord généré par le script. Je trace A1, B2, par exemple, comme dans une grille Excel. Les tableaux de bord de Lokad sont organisés de manière similaire aux grilles d’Excel, avec des positions comportant les colonnes B, C, etc., et les lignes 1, 2, 3, 4, 5.
Vous pouvez voir que la convolution discrète, Z, présente un schéma très étrange et extrêmement pointu, que l’on retrouve très couramment 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 avez besoin d’un langage de programmation qui mette ces capacités à votre disposition, en tant que citoyens de première classe. C’est exactement de cela qu’il s’agit en programmation probabiliste, et c’est ainsi que nous l’avons implémenté dans Envision.
Maintenant, discutons de la programmation différentiable. Je dois préciser 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 fasse défaut ; c’est juste que ce sujet mérite toute une série de conférences. En fait, si vous regardez le programme des prochaines conférences, il y a toute une série dédiée à la programmation différentiable. Je vais aller très vite, et ce sera assez cryptique, donc je m’excuse par avance.
Passons au problème de supply chain qui nous intéresse ici, à savoir la cannibalisation et la substitution. Ces problèmes sont très intéressants, et ils représentent probablement le cas 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, des clients ou prospects viennent me voir et me demandent si nous pouvons réaliser, par exemple, des prévisions sur 13 semaines pour certains articles comme des sacs à dos. Je dirais oui, nous 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 allez-vous concentrer toute la demande pour les sacs à dos sur ce seul produit. Si vous introduisez 10 variantes différentes, il y aura évidemment beaucoup de cannibalisation. Vous n’allez pas multiplier le volume total des ventes par un facteur de 10 simplement parce que vous avez multiplié le nombre de références par 10. Il y a donc évidemment une cannibalisation et une substitution qui se produisent. Ces phénomènes sont répandus dans les supply chains.
Comment analyser la cannibalisation ou la substitution ? La manière dont nous procédons chez Lokad, et je ne prétends pas que ce soit la seule méthode, mais c’est certainement une approche qui fonctionne, consiste typiquement à examiner le graphe qui relie les clients aux produits. Pourquoi cela ? Parce que la cannibalisation se produit lorsque des produits sont en concurrence entre eux pour les mêmes clients. La cannibalisation est littéralement le reflet du fait qu’un client a un besoin, mais qu’il a des préférences et va choisir un produit parmi l’ensemble des produits correspondant à son affinité, et en sélectionner un seul. Voilà l’essence même de la cannibalisation.
Si vous voulez analyser cela, vous devez étudier non pas les séries temporelles des ventes, car vous ne capturez pas cette information dès le départ. Vous souhaitez analyser le graphe qui relie les transactions historiques entre clients et produits. Il s’avère que, dans la plupart des entreprises, ces données sont facilement disponibles. Pour le e-commerce, c’est acquis. 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 distribution disposent de programmes de loyalty où elles identifient un pourcentage à deux chiffres des clients qui se présentent avec leurs cartes, de sorte que vous savez qui achète quoi. Pas pour 100 % du trafic, mais cela suffit pour ce type d’analyse.
Dans ce petit extrait, je vais détailler une analyse d’affinité entre clients et produits. C’est littéralement l’étape fondamentale à réaliser pour effectuer toute analyse de cannibalisation. Voyons ce qui se passe dans ce code.
De la ligne un à cinq, c’est très banal ; je me contente de lire un fichier plat qui contient un historique de transactions. Je lis simplement un fichier CSV qui possède quatre colonnes : date, produit, client et quantité. Quelque chose de très basique. Je n’utilise même pas toutes ces colonnes, mais c’est juste pour rendre l’exemple un peu plus concret. Dans l’historique des transactions, je suppose que les clients sont identifiés pour l’ensemble de ces opérations. Donc, c’est très banal ; je lis simplement des données provenant d’un tableau.
Ensuite, aux lignes sept et huit, je me contente de créer la table pour les produits et la table pour les clients. Dans un environnement de production réel, je ne créerais généralement pas ces tables ; je les lirais à partir d’autres fichiers plats situés ailleurs. Je voulais garder l’exemple ultra simple, alors j’extrais simplement une table de produits à partir des produits observés dans l’historique des transactions, et je fais de même pour les clients. Vous voyez, c’est juste une astuce pour simplifier l’exemple.
Maintenant, les lignes 10, 11 et 12 concernent des espaces latins, et cela va devenir un peu plus obscur. D’abord, à la ligne 10, je crée un tableau de 64 lignes. Le tableau ne contient rien ; il est uniquement défini par le fait qu’il comporte 64 lignes, et c’est tout. C’est donc comme un espace réservé, un tableau trivial avec beaucoup de lignes et aucune colonne. Ce n’est pas très utile en l’état. Ensuite, « P » est fondamentalement un produit cartésien, une opération mathématique qui forme toutes les paires. C’est un tableau où vous avez une ligne pour chaque ligne des produits et chaque ligne du tableau « L ». Ainsi, ce tableau « 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 grâce à cette dimension supplémentaire, qui est ce tableau « L ».
Ceci servira de support pour mes espaces latins, que je vais justement apprendre. Ce que je souhaite apprendre, c’est que, pour chaque produit, il existe un espace latin qui sera un vecteur de 64 valeurs, et pour chaque client, également un espace latin de 64 valeurs. Si je veux connaître l’affinité entre un client et un produit, je veux simplement pouvoir calculer le produit scalaire entre les deux. Le produit scalaire consiste simplement en la multiplication terme à terme de tous les éléments de ces deux vecteurs, suivie d’une sommation. Cela peut sembler très technique, mais c’est simplement une multiplication terme à terme plus une somme – c’est le produit scalaire.
Ces espaces latins ne sont qu’un jargon sophistiqué pour créer un espace avec des paramètres un peu inventés, que je souhaite simplement apprendre. Toute la magie de la programmation différentiable s’opère en à peine cinq lignes, de la ligne 14 à la 18. J’ai un mot-clé, « autodiff », et « transactions », ce qui indique qu’il s’agit d’un tableau d’intérêt, un tableau d’observations. Je vais traiter ce tableau ligne par ligne pour effectuer mon processus d’apprentissage. Dans ce bloc, je déclare un ensemble de paramètres. Les paramètres sont les éléments que vous souhaitez apprendre, à l’image de nombres dont vous ne connaissez pas encore les valeurs. Ces éléments vont simplement être initialisés aléatoirement, avec des nombres aléatoires.
J’introduis « X », « X* » et « Y ». Je ne vais pas entrer dans le détail de ce que fait exactement « X* » ; peut-être lors des 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 matricielle est simplement que vous souhaitez apprendre des espaces latins qui correspondent à tous les liens de votre graphe bipartite. Je sais que c’est un peu technique, mais ce que nous faisons est littéralement très simple, du point de vue de la supply chain. Nous apprenons l’affinité entre les produits et les clients.
Je sais que cela semble probablement très opaque, mais restez avec moi, et il y aura d’autres conférences où je vous offrirai une introduction plus approfondie à ce sujet. Le tout se fait en cinq lignes, ce qui est tout à fait remarquable. Quand je dis cinq lignes, je ne triche pas en disant : « Regardez, ce ne sont que cinq lignes, mais j’appelle en réalité une bibliothèque tierce d’une complexité gigantesque dans laquelle toute l’intelligence est enfouie. » Non, non, non. Ici, dans cet exemple, il n’y a littéralement aucune magie de machine learning en dehors des deux mots-clés « autodiff » et « params ». « Autodiff » est utilisé pour définir un bloc où la programmation différentiable va s’opérer, et d’ailleurs, c’est un bloc dans lequel je peux programmer n’importe quoi, ce qui signifie que je peux littéralement injecter notre programme. Ensuite, j’utilise « params » pour déclarer mes problèmes, et voilà. Vous voyez, il n’y a aucune magie opaque en jeu ; il n’existe pas une bibliothèque d’un million de lignes en arrière-plan qui fait tout le travail à votre place. Tout ce que vous devez savoir se trouve littéralement à l’écran, et c’est là toute 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, telles que réaliser une analyse de cannibalisation en 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 obtenir quelque chose qui semble super compliqué résolu en quelques lignes seulement.
Maintenant, quelques mots sur le fonctionnement de la programmation différentiable. Il y a deux idées clés. 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 méthodes pour calculer des dérivées. Il y a la dérivée symbolique, par exemple, si vous avez x au carré, vous calculez la dérivée par rapport à x, ce qui donne 2x. C’est la dérivée symbolique. Puis, il y a la dérivée numérique, donc si vous avez une fonction f(x) que vous souhaitez différencier, ce sera f’(x) ≈ (f(x + ε) - f(x))/ε. C’est la dérivation numérique. Aucun des deux n’est adapté à ce que nous essayons de faire ici. La dérivation symbolique pose des problèmes de complexité, car votre dérivée pourrait être un programme bien plus complexe que le programme original. La dérivation numérique est numériquement instable, vous rencontrerez donc de nombreux 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 grand public 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 quelconque, ce qui est époustouflant. Encore plus incroyable, le programme qui est la dérivée possède la même complexité computationnelle que le programme original, ce qui est stupéfiant. La programmation différentiable est simplement une combinaison de différentiation automatique et de paramètres que vous souhaitez apprendre.
Alors, comment apprendre ? Une fois la dérivation obtenue, cela signifie que vous pouvez remonter les gradients, et grâce à la descente de gradient stochastique, vous pouvez ajuster légèrement les valeurs des paramètres. En modifiant ces paramètres, vous convergerez progressivement, au travers de nombreuses itérations de descente de gradient stochastique, vers des paramètres qui ont du sens et qui permettent d’atteindre ce que vous souhaitez apprendre ou optimiser.
La programmation différentiable peut être utilisée pour des problèmes d’apprentissage, comme celui que j’illustre, où je souhaite 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 paramètres sous contraintes, et c’est un paradigme très évolutif. Comme vous pouvez le constater, cet aspect a été élevé au rang de citoyen de première classe dans Envision. D’ailleurs, il y a encore quelques éléments en cours de développement en termes de syntaxe Envision, donc n’attendez pas encore exactement ces fonctionnalités ; nous sommes encore en train d’affiner certains aspects. Mais l’essentiel est là. Je ne vais pas discuter des détails des quelques éléments qui sont encore en évolution.
Passons maintenant à un autre problème pertinent pour la préparation opérationnelle de votre système. Typiquement, dans l’optimisation de la supply chain, vous êtes confronté à 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 dénués de sens. Par exemple, vous avez réalisé un calcul en batch pour le réapprovisionnement de stocks pendant la nuit, et le matin, vous découvrez que certains de ces résultats étaient aberrants, entraînant des erreurs coûteuses. Vous ne voulez pas que le problème se reproduise, alors vous relancez votre processus. Cependant, lorsque vous exécutez de nouveau le processus, le problème a disparu. Vous ne pouvez pas reproduire l’incident, et le Heisenbug ne se manifeste plus.
Cela peut sembler être un cas limite étrange, mais dans les premières années de Lokad, nous avons rencontré ces problèmes à maintes reprises. J’ai vu de nombreuses initiatives en supply chain, notamment dans le domaine de la data science, échouer à cause de Heisenbugs non résolus. Les bugs survenaient en production, on essayait de reproduire les problèmes en local sans succès, et les problèmes n’étaient donc jamais corrigés. Après quelques mois en mode panique, le projet entier était généralement fermé discrètement, et les gens retournaient à l’utilisation de feuilles de calcul Excel.
Si vous souhaitez obtenir une reproductibilité totale de votre logique, vous devez versionner à la fois le code et les données. La plupart des personnes dans l’audience qui sont ingénieurs logiciels ou data scientists connaissent probablement l’idée de versionner le code. Cependant, vous devez aussi versionner toutes les données afin que, lorsque votre programme s’exécute, vous sachiez exactement quelle version du code et quelles données sont utilisées. Il se peut que vous ne puissiez pas reproduire le problème le lendemain parce que les données auront évolué en raison de nouvelles transactions ou d’autres facteurs, et les conditions à l’origine du bug ne seront plus réunies.
Vous devez 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 requiert une version complète de tout. Encore une fois, le langage de programmation et la pile technologique doivent coopérer pour que cela soit possible. C’est réalisable sans que le paradigme de programmation ne soit un citoyen de première classe de votre pile, mais dans ce cas, le Supply Chain Scientist doit être extrêmement prudent quant à tout ce qu’il fait et à la manière dont il programme. Sinon, il ne pourra pas reproduire ses résultats. Cela met une pression immense sur les épaules des Supply Chain Scientists, qui sont déjà soumis à une pression considérable de la supply chain elle-même. Vous ne voulez pas que ces professionnels aient à faire face à une complexité accidentelle, comme l’incapacité à reproduire leurs propres résultats. Chez Lokad, nous appelons cela une “time machine” où vous pouvez reproduire tout à 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 coup. Par exemple, si vous passez un bon de commande à un fournisseur qui a un délai de trois mois, vous pouvez découvrir trois mois plus tard que la commande était aberrante. Vous devez remonter trois mois dans le temps jusqu’au moment où vous avez généré ce bon de commande erroné afin de comprendre ce qui n’allait pas. Il ne s’agit pas de versionner seulement les dernières heures de travail ; il s’agit littéralement de disposer d’un historique complet de l’exécution de l’année passée.
Un autre enjeu est la montée en puissance des ransomwares et des cyberattaques sur les supply chains. Ces attaques sont extrêmement perturbatrices et peuvent coûter très cher. Lors de la mise en œuvre de solutions pilotées par logiciel, vous devez vous demander si vous ne rendez pas votre entreprise et votre supply chain plus vulnérables aux cyberattaques et aux risques. Dans cette optique, 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 Scientist traitant 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, commun 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 conférez 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é délinquant intentionnel, mais même en mettant cela de côté, vous avez toujours le problème que quelqu’un expose accidentellement une partie interne des systèmes informatiques. Rappelez-vous, les systèmes d’optimization de la supply chain, par définition, ont accès à une grande quantité de données dans toute l’entreprise. Ces données ne sont pas seulement un atout, mais aussi un passif.
Ce que vous voulez, c’est un paradigme de programmation qui favorise une programmation sécurisée. Vous voulez un langage de programmation où il existe des catégories entières de choses que vous ne pouvez pas faire. Par exemple, pourquoi devrait-on avoir un langage de programmation capable d’effectuer des appels système à des fins d’optimization de la supply chain? Python peut effectuer des appels système, tout comme Excel. Mais pourquoi voudriez-vous, en premier lieu, un système programmable avec de telles capacités? C’est comme acheter une arme pour se tirer une balle dans le pied.
Vous voulez quelque chose où des catégories entières ou des fonctionnalités sont absentes parce que vous n’en avez pas besoin pour l’optimization de la supply chain. Si ces fonctionnalités sont présentes, elles deviennent un passif massif. Si vous introduisez des capacités programmables sans les outils qui imposent une programmation sécurisée dès la conception, vous augmentez le risque de cyberattaques et de rançongiciels, aggravant la situation.
Bien sûr, il est toujours possible de compenser en doublant la taille de l’équipe de cybersécurité, mais cela coûte très cher et n’est 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 habituels, les revues et les validations. Vous voulez également une programmation sécurisée qui élimine les problèmes banals tels que les exceptions de référence nulle, les erreurs de mémoire insuffisante, les boucles décalées d’un, et les effets de bord.
En conclusion, les outils comptent. Il y a un adage : “Don’t bring a sword to a gunfight.” Vous avez besoin des bons outils et des bons paradigmes de programmation, pas seulement de ceux que vous avez appris à l’université. Vous avez besoin de quelque chose de professionnel et de qualité production pour répondre aux besoins de votre supply chain. Bien que vous puissiez obtenir quelques résultats avec des outils médiocres, ce ne sera pas excellent. Un musicien fantastique peut faire de la musique avec une simple cuillère, mais avec un instrument adapté, il peut faire bien 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 lisant 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 souhaitez effectuer une opération algorithmique ou résoudre un problème donné, vous allez répéter très fréquemment la même sous-opération. La programmation dynamique est un cas spécifique du compromis espace-temps que j’ai mentionné précédemment, où vous investissez un peu plus en mémoire pour gagner du temps au niveau du 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 mal choisi car il n’y a rien de vraiment dynamique dans ce concept, et ce n’est pas vraiment une question de programmation. C’est davantage lié à la conception des 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 s’il vous plaît fournir quelques livres de référence que tout bon ingénieur 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 summum 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. Fondamentalement, on trouve des personnes qui présentent des collections de recettes numériques simplistes pour des supply chains idéalisées, et je pense que ces livres n’abordent pas la supply chain sous le bon angle, et manquent complètement le fait qu’il s’agit d’un problème épineux. Il existe un vaste corpus de littérature très technique, avec des équations, des algorithmes, des théorèmes et des preuves, mais je pense qu’elle passe complètement à côté de l’essentiel.
Ensuite, il y a un autre style de livres sur la gestion de la supply chain, qui est plus de type consultant. Vous pouvez facilement reconnaître ces livres car ils utilisent des analogies sportives toutes les deux pages. Ces livres comportent toutes sortes de diagrammes simplistes, comme des variantes 2x2 des matrices SWOT (Forces, Faiblesses, Opportunités, Menaces), que je considère comme des méthodes de raisonnement de faible qualité. Le problème avec ces livres, c’est qu’ils semblent mieux comprendre que la supply chain est une entreprise épineuse. Ils comprennent beaucoup mieux qu’il s’agit d’un jeu joué par des personnes, où toutes sortes de situations bizarres peuvent se produire, et où vous pouvez faire preuve d’intelligence en termes de méthodes. Je leur rends hommage pour cela. Le problème avec ces livres, typiquement écrits par des consultants ou des professeurs d’écoles de management, c’est qu’ils ne sont pas très exploitables. Le message se résume à “soyez un meilleur leader”, “soyez plus intelligent”, “ayez plus d’énergie”, et pour moi, cela n’est pas exploitable. Cela ne vous donne pas des éléments que vous pouvez transformer en quelque chose de très précieux, comme le peut le logiciel.
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 soit une utilisation judicieuse du temps. Il est bon de savoir ce que les gens ont écrit. Du côté de la littérature consultant, mon préféré est probablement le travail de Katana, que je n’ai pas mentionné lors de la première conférence. Tout n’est pas mauvais ; certaines personnes ont plus de talent, même si elles sont plus dans le style consultant. Vous pouvez consulter le travail de Katana ; il a un livre sur les supply chains dynamiques. Je l’indiquerai dans les références.
Question: Comment utilisez-vous la parallélisation lorsqu’il s’agit de cannibalisation ou de décisions d’assortiment, où le problème n’est pas aisément parallélisable ?
Pourquoi n’est-ce pas aisément parallélisable ? La descente de gradient stochastique est assez triviale à paralléliser. Vous avez des étapes de gradient stochastique qui peuvent être effectuées dans des ordres aléatoires, et vous pouvez en avoir plusieurs simultanément. Donc, je pense que tout ce qui est entraîné par la descente de gradient stochastique est assez facile à paralléliser.
Lorsqu’il s’agit de cannibalisation, ce qui est plus difficile, c’est de gérer un autre type de parallélisation, qui concerne ce qui vient en premier. Si je place ce produit en premier, puis que je réalise une prévision, mais ensuite que je prends un autre produit, cela modifie le paysage. La solution est d’avoir un moyen d’aborder l’ensemble du paysage de manière frontale. Vous ne dites pas : “D’abord, j’introduis ce produit et je fais la prévision ; ensuite, j’introduis un autre produit et je refais la prévision, modifiant la première.” Vous le faites de manière frontale, toutes ces choses en même temps, simultanément. Vous avez besoin de plus de paradigmes de programmation. Les paradigmes de programmation que j’ai présentés aujourd’hui peuvent y contribuer grandement.
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 distribution mondial et que vous souhaitez optimiser l’assortiment pour tous vos magasins. Vous pouvez effectuer des calculs 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 suivant. C’est une mauvaise façon de procéder, 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 aisée.
Question: Utilisez-vous une approche de base de données graphe ?
Non, pas dans le sens technique et canonique. Il existe de nombreuses bases de données graphe sur le marché qui sont d’un grand intérêt. Ce que nous utilisons en interne chez Lokad, c’est une intégration verticale complète via un compilateur monolithique unifié afin d’éliminer totalement tous les éléments traditionnels que l’on trouve dans une pile classique. C’est ainsi que nous obtenons de très bonnes performances, en termes de performance de calcul, très proches du métal. Non pas parce que nous sommes des codeurs extraordinairement intelligents, mais simplement parce que nous avons éliminé à peu près toutes les couches qui existent traditionnellement. Lokad n’utilise littéralement aucune base de données. Nous avons un compilateur qui prend en charge tout, jusqu’à l’organisation des structures de données pour la persistance. C’est un peu étrange, mais c’est beaucoup plus efficace de procéder ainsi, et de cette manière, vous jouez beaucoup mieux 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 unique ; c’est une flotte de machines.
Question: Quel est votre avis sur Power BI, qui exécute également des codes Python et des algorithmes associés tels que la descente de gradient, glouton, etc. ?
Le problème que j’ai avec tout ce qui touche à l’intelligence d’affaires, Power BI en étant un exemple, est qu’il adopte un paradigme que je trouve inadapté à la supply chain. Vous voyez tous les problèmes comme un hypercube, où vous avez des dimensions que vous ne faites que trancher et découper. Au cœur, il y a un problème d’expressivité, qui est très limitatif. 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 des logiciels enterprise software modernes, c’est qu’il y a trop de couches. Chaque couche que vous ajoutez va introduire des inefficacités et des bugs. Si vous utilisez Power BI avec Python, vous aurez bien trop de couches. Ainsi, vous avez Power BI qui se situe au-dessus d’autres systèmes, ce qui signifie que vous possédez déjà plusieurs systèmes avant Power BI. Ensuite, vous avez Power BI au-dessus, et par-dessus Power BI, vous avez Python. Mais est-ce que Python agit de lui-même ? Non, il y a de fortes chances que vous utilisiez des bibliothèques Python, comme Pandas ou NumPy. Vous vous retrouvez donc avec des couches dans Python qui vont s’empiler, et vous finissez avec des dizaines de couches. Vous pouvez avoir des bugs dans n’importe laquelle de ces couches, de sorte que la situation va être tout simplement un cauchemar.
Je ne crois pas en ces solutions où l’on se retrouve avec un nombre massif de piles. Il y a cette blague selon laquelle en C++, on peut toujours résoudre n’importe quel problème en ajoutant une couche supplémentaire d’indirection, y compris pour le problème d’avoir trop de couches d’indirection. Évidemment, cela est un peu absurde en tant qu’énoncé, mais je suis profondément en désaccord avec l’approche selon laquelle les gens ont un produit avec une conception de noyau inadéquate, et qu’au lieu d’aborder le problème de front, ils finissent par empiler des éléments au-dessus alors que les fondations sont fragiles. Ce n’est pas la bonne manière de faire, et vous allez avoir une productivité médiocre, des combats incessants avec des bugs que vous ne résoudrez jamais, et ensuite, en termes de maintenabilité, c’est tout simplement une recette pour un cauchemar.
Question: Comment les résultats d’une analyse par filtrage collaboratif peuvent-ils être intégrés dans l’algorithme de prévision de la demande pour chaque produit, par exemple pour des sacs à dos ?
Je suis désolé, mais j’aborderai ce sujet lors de la prochaine conférence. La réponse courte est que vous ne voulez pas intégrer cela dans un algorithme de prévision existant. Vous voulez quelque chose de bien plus intégré nativement. Vous ne faites pas cela pour ensuite revenir à vos anciennes méthodes de prévision ; au lieu de cela, vous abandonnez simplement l’ancienne manière de faire la prévision et faites quelque chose de radicalement différent qui en tire parti. Mais j’en discuterai lors d’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, à la même heure, le même jour de la semaine. Je prendrai quelques vacances de Noël, donc je souhaite à tous un joyeux Noël et une bonne année. Nous reprendrons notre série de conférences l’année prochaine. Merci beaucoup.
