00:19 Introduction
04:33 Deux définitions pour ‘algorithme’
08:09 Big-O
13:10 L’histoire jusqu’à présent
15:11 Sciences auxiliaires (récapitulatif)
17:26 Algorithmes modernes
19:36 Dépasser l’« optimalité »
22:23 Structures de données - 1/4 - Liste
25:50 Structures de données - 2/4 - Arbre
27:39 Structures de données - 3/4 - Graphe
29:55 Structures de données - 4/4 - Table de hachage
31:30 Recettes magiques - 1/2
37:06 Recettes magiques - 2/2
39:17 Compréhension des tenseurs - 1/3 - La notation ‘Einstein’
42:53 Compréhension des tenseurs - 2/3 - La percée de l’équipe de Facebook
46:52 Compréhension des tenseurs - 3/3 - Perspective de la supply chain
52:20 Méta-techniques - 1/3 - Compression
56:11 Méta-techniques - 2/3 - Mémoïsation
58:44 Méta-techniques - 3/3 - Immutabilité
01:03:46 Conclusion
01:06:41 Prochain cours et questions du public
Description
L’optimisation des supply chains repose sur la résolution de nombreux problèmes numériques. Les algorithmes sont des recettes numériques hautement codifiées destinées à résoudre des problèmes de calcul précis. Des algorithmes supérieurs signifient que des résultats supérieurs peuvent être obtenus avec moins de ressources informatiques. En se concentrant sur les spécificités de la supply chain, les performances algorithmiques peuvent être considérablement améliorées, parfois de plusieurs ordres de grandeur. Les algorithmes de la “supply chain” doivent également prendre en compte la conception des ordinateurs modernes, qui a considérablement évolué au cours des dernières décennies.
Transcription complète
Bienvenue dans cette série de cours sur la supply chain. Je suis Joannes Vermorel et aujourd’hui je vais présenter “Les algorithmes modernes pour la supply chain”. Des capacités de calcul supérieures sont essentielles pour obtenir de meilleures performances de la supply chain. Des prévisions plus précises, une optimisation plus fine et une optimisation plus fréquente sont toutes souhaitables pour obtenir de meilleures performances de la supply chain. Il y a toujours une méthode numérique supérieure juste légèrement au-delà des ressources informatiques que vous pouvez vous permettre.
Les algorithmes, pour simplifier, permettent aux ordinateurs d’aller plus vite. Les algorithmes sont une branche des mathématiques, et c’est un domaine de recherche très actif. Les progrès dans ce domaine de recherche dépassent souvent les progrès du matériel informatique lui-même. L’objectif de ce cours est de comprendre ce que sont les algorithmes modernes et, plus spécifiquement, du point de vue de la supply chain, comment aborder les problèmes afin de tirer le meilleur parti de ces algorithmes modernes pour votre supply chain.
En termes d’algorithmes, il y a un livre qui est une référence absolue : Introduction aux algorithmes, publié pour la première fois en 1990. C’est un livre incontournable. La qualité de la présentation et de l’écriture est tout simplement exceptionnelle. Ce livre s’est vendu à plus d’un demi-million d’exemplaires au cours de ses 20 premières années de vie et a inspiré toute une génération d’écrivains universitaires. En fait, la plupart des livres récents sur la supply chain traitant de la théorie de la supply chain qui ont été publiés au cours de la dernière décennie ont souvent été fortement inspirés par le style et la présentation de ce livre.
Personnellement, j’ai lu ce livre pour la première fois en 1997, et c’était en fait une traduction française de la toute première édition. Il a eu une influence profonde sur toute ma carrière. Après avoir lu ce livre, je n’ai plus jamais vu les logiciels de la même manière. Un mot de prudence, cependant, est que ce livre adopte une perspective sur le matériel informatique qui prévalait à la fin des années 80 et au début des années 90. Comme nous l’avons vu dans les cours précédents de cette série, le matériel informatique a progressé de manière assez spectaculaire au cours des deux dernières décennies, et donc certaines des hypothèses formulées dans ce livre semblent relativement dépassées. Par exemple, le livre suppose que les accès à la mémoire ont un temps constant, quelle que soit la quantité de mémoire que vous souhaitez adresser. Ce n’est plus ainsi que fonctionnent les ordinateurs modernes.
Néanmoins, je pense qu’il y a certaines situations où être simpliste est une proposition raisonnable si ce que vous gagnez en échange est un degré de clarté et de simplicité d’exposition beaucoup plus élevé. Ce livre fait un travail incroyable à cet égard. Bien que je conseille de garder à l’esprit que certaines des hypothèses clés formulées tout au long du livre sont dépassées, il reste une référence absolue que je recommanderais à l’ensemble du public.
Clarifions le terme “algorithme” pour le public qui pourrait ne pas être très familier avec cette notion. Il y a la définition classique selon laquelle c’est une séquence finie d’instructions informatiques bien définies. C’est le genre de définition que vous trouverez dans les manuels ou sur Wikipedia. Bien que la définition classique d’un algorithme ait ses mérites, je pense qu’elle est décevante, car elle ne clarifie pas l’intention associée aux algorithmes. Ce n’est pas n’importe quelle séquence d’instructions qui est intéressante ; c’est une séquence très spécifique d’instructions informatiques. Ainsi, je propose une définition personnelle du terme algorithme : un algorithme est essentiellement une méthode logicielle axée sur la résolution de problèmes, orientée performance et fine-grained.
Décomposons cette définition, voulez-vous ? Tout d’abord, la partie résolution de problèmes : un algorithme est entièrement caractérisé par le problème qu’il essaie de résoudre. Sur cet écran, vous pouvez voir le pseudocode de l’algorithme Quicksort, qui est un algorithme populaire et bien connu. Quicksort essaie de résoudre le problème de tri, qui est le suivant : vous avez un tableau qui contient des entrées de données, et vous voulez un algorithme qui renvoie le même tableau mais avec toutes les entrées triées par ordre croissant. Les algorithmes se concentrent entièrement sur un problème spécifique et bien défini.
Le deuxième aspect est la façon dont vous jugez que vous avez un meilleur algorithme. Un meilleur algorithme est quelque chose qui vous permet de résoudre le même problème avec moins de ressources informatiques, ce qui signifie en pratique plus rapidement. Enfin, il y a la partie fine-grained. Lorsque nous utilisons le terme “algorithmes”, cela implique que nous voulons examiner des problèmes très élémentaires qui sont modulaires et peuvent être composés à l’infini pour résoudre des problèmes beaucoup plus complexes. C’est vraiment de cela que parlent les algorithmes.
Une réalisation clé de la théorie des algorithmes est de fournir une caractérisation des performances des algorithmes de manière assez abstraite. Je n’aurai pas le temps aujourd’hui d’entrer dans les détails de cette caractérisation et du cadre mathématique. L’idée est que, pour caractériser l’algorithme, nous voulons examiner le comportement asymptotique. Nous avons un problème qui dépend d’une ou plusieurs dimensions clés qui caractérisent le problème. Par exemple, dans le problème de tri que j’ai présenté précédemment, la dimension caractéristique est généralement le nombre d’éléments à trier. La question est : que se passe-t-il lorsque le tableau d’éléments à trier devient très grand ? Je vais désigner cette dimension caractéristique par le nombre “n” par convention.
Maintenant, j’ai cette notation, la notation Big O, que vous avez peut-être déjà vue lorsque vous traitez des algorithmes. Je vais simplement donner quelques éléments pour vous donner une intuition de ce qui se passe. Tout d’abord, disons, par exemple, que nous avons un ensemble de données et que nous voulons extraire un indicateur statistique simple comme une moyenne. Si je dis que j’ai un algorithme Big O de 1, cela signifie que je suis capable de renvoyer une solution à ce problème (calculer la moyenne) en temps constant, que le jeu de données soit petit ou grand. Le temps constant, ou Big O de 1, est une exigence absolue chaque fois que vous voulez faire quelque chose qui est en temps réel dans le sens de la communication machine à machine. Si vous n’avez pas quelque chose qui est en temps constant, il est très difficile, voire impossible, d’obtenir des performances en temps réel.
Typiquement, un autre aspect clé des performances est le Big O de N. Le Big O de N signifie que vous avez une complexité pour l’algorithme qui est strictement linéaire par rapport à la taille de l’ensemble de données d’intérêt. C’est ce que vous obtenez lorsque vous avez une implémentation efficace qui est capable de résoudre le problème en lisant simplement les données une fois ou un nombre fixe de fois. La complexité Big O de N est généralement compatible uniquement avec l’exécution par lots. Si vous voulez avoir quelque chose qui est en ligne et en temps réel, vous ne pouvez pas avoir quelque chose qui parcourt l’ensemble des données, à moins de savoir que votre ensemble de données a une taille fixe.
Au-delà de la linéarité, vous avez le Big O de N au carré. Le Big O de N au carré est un cas très intéressant car c’est le point optimal de l’explosion de la production. Cela signifie que la complexité croît de manière quadratique par rapport à la taille de l’ensemble de données, ce qui signifie que si vous avez 10 fois plus de données, vos performances seront 100 fois plus mauvaises. C’est généralement le genre de performances où vous ne verrez aucun problème dans le prototype car vous travaillez avec de petits ensembles de données. Vous ne verrez aucun problème lors de la phase de test car, encore une fois, vous travaillez avec de petits ensembles de données. Dès que vous passez en production, vous avez un logiciel qui est complètement lent. Très fréquemment dans le monde des logiciels d’entreprise, en particulier dans le monde des logiciels d’entreprise de la supply chain, la plupart des problèmes de performance abyssaux que vous pouvez observer sur le terrain sont en réalité causés par des algorithmes quadratiques qui n’ont pas été identifiés. En conséquence, vous observez le comportement quadratique qui est tout simplement très lent. Ce problème n’a pas été identifié dès le départ car les ordinateurs modernes sont assez rapides et N au carré n’est pas si mauvais tant que N est assez petit. Cependant, dès que vous traitez un ensemble de données de production à grande échelle, cela fait beaucoup de mal.
Cette conférence est en réalité la deuxième conférence de mon quatrième chapitre de cette série de conférences sur la supply chain. Dans le premier chapitre, le prologue, j’ai présenté mes points de vue sur la supply chain à la fois en tant que domaine d’étude et en tant que pratique. Ce que nous avons vu, c’est que la supply chain est une grande collection de problèmes complexes, par opposition aux problèmes simples. Les problèmes complexes ne peuvent pas être abordés par des méthodologies naïves car vous avez des comportements adverses partout et vous devez donc accorder une grande attention à la méthodologie elle-même. La plupart des méthodes naïves échouent de manière assez spectaculaire. C’est exactement ce que j’ai fait dans le deuxième chapitre, qui est entièrement consacré aux méthodologies adaptées à l’étude des supply chains et à l’amélioration de la pratique de la gestion de la supply chain. Le troisième chapitre, qui n’est pas encore terminé, est essentiellement un zoom sur ce que j’appelle “le personnel de la supply chain”, une méthodologie très spécifique où nous nous concentrons sur les problèmes eux-mêmes plutôt que sur les solutions que nous pouvons envisager pour résoudre le problème. À l’avenir, j’alternerai entre le chapitre numéro trois et le chapitre actuel, qui concerne les sciences auxiliaires de la supply chain.
Lors de la dernière conférence, nous avons vu que nous pouvons obtenir plus de capacités de calcul pour notre supply chain grâce à un matériel informatique meilleur et plus moderne. Aujourd’hui, nous examinons le problème sous un autre angle - nous recherchons plus de capacités de calcul car nous disposons de meilleurs logiciels. C’est ce que sont les algorithmes.
Un bref rappel : les sciences auxiliaires sont essentiellement une perspective sur la supply chain elle-même. La conférence d’aujourd’hui ne concerne pas strictement la supply chain ; elle concerne les algorithmes. Cependant, je pense qu’elle revêt une importance fondamentale pour la supply chain. La supply chain n’est pas une île ; les progrès qui peuvent être réalisés dans la supply chain dépendent fortement des progrès déjà réalisés dans d’autres domaines adjacents. Je fais référence à ces domaines en tant que sciences auxiliaires de la supply chain.
Je pense que la situation est assez similaire à la relation entre les sciences médicales et la chimie au cours du XIXe siècle. Au tout début du XIXe siècle, les sciences médicales ne se souciaient pas du tout de la chimie. La chimie était encore le petit nouveau et n’était pas considérée comme une proposition valable pour un patient réel. Avance rapide jusqu’au XXIe siècle, la proposition selon laquelle vous pouvez être un excellent médecin tout en ne connaissant rien à la chimie serait considérée comme complètement absurde. Il est admis qu’être un excellent chimiste ne fait pas de vous un excellent médecin, mais il est généralement admis que si vous ne connaissez rien à la chimie du corps, vous ne pouvez pas être compétent en ce qui concerne les sciences médicales modernes. Mon point de vue pour l’avenir est que pendant le XXIe siècle, le domaine de la supply chain commencera à considérer le domaine des algorithmes de la même manière que le domaine des sciences médicales a commencé à regarder la chimie au cours du XIXe siècle.
Les algorithmes sont un vaste domaine de recherche, une branche des mathématiques, et nous ne ferons qu’effleurer la surface de ce domaine de recherche aujourd’hui. En particulier, ce domaine de recherche accumule des résultats étonnants depuis des décennies. C’est peut-être un domaine de recherche assez théorique, mais cela ne signifie pas que ce n’est que de la théorie. En réalité, c’est un domaine de recherche assez théorique, mais il y a eu des tonnes de découvertes qui ont trouvé leur place dans la production.
En fait, n’importe quel type de smartphone ou d’ordinateur que vous utilisez aujourd’hui utilise littéralement des dizaines de milliers d’algorithmes qui ont été publiés à l’origine quelque part. Ce bilan est en réalité beaucoup plus impressionnant par rapport à la théorie de la supply chain, où la grande majorité des supply chains ne fonctionnent pas sur la base des découvertes de la théorie de la supply chain, du moins pas encore. En ce qui concerne les ordinateurs modernes et les algorithmes modernes, pratiquement tout ce qui est lié aux logiciels est entièrement basé sur toutes ces décennies de découvertes de la recherche algorithmique. C’est très présent au cœur de pratiquement tous les ordinateurs que nous utilisons aujourd’hui.
Pour la conférence d’aujourd’hui, j’ai sélectionné une liste de sujets que je pense être assez illustratifs de ce que vous devriez savoir pour aborder le sujet des algorithmes modernes. Tout d’abord, nous discuterons de la façon dont nous pouvons réellement surpasser les algorithmes supposément optimaux, en particulier pour la supply chain. Ensuite, nous jetterons un coup d’œil rapide aux structures de données, suivi de recettes magiques, de la compression des tenseurs, et enfin, des méta-techniques.
Tout d’abord, je tiens à préciser que lorsque je parle “d’algorithmes pour la supply chain”, je ne veux pas dire des algorithmes destinés à résoudre des problèmes spécifiques à la supply chain. La perspective correcte est de regarder les algorithmes classiques pour les problèmes classiques et de revisiter ces problèmes classiques d’un point de vue de la supply chain pour voir si nous pouvons réellement faire mieux. La réponse est oui, nous le pouvons.
Par exemple, l’algorithme de tri rapide, selon la théorie générale des algorithmes, est optimal dans le sens où vous ne pouvez pas introduire un algorithme qui soit arbitrairement meilleur que le tri rapide. Donc, à cet égard, le tri rapide est aussi bon qu’il peut l’être. Cependant, si nous nous concentrons spécifiquement sur la supply chain, il est possible d’obtenir des accélérations impressionnantes. En particulier, si nous examinons des problèmes de tri où la cardinalité des ensembles de données d’intérêt est faible, tels que les dates, les prix, les niveaux de stocks ou les catégories, tous ces ensembles de données ont une faible cardinalité. Ainsi, si vous avez des hypothèses supplémentaires, telles que le fait d’être dans une situation de faible cardinalité, vous pouvez utiliser le tri par compartiment. En production, il existe de nombreuses situations où vous pouvez obtenir des accélérations absolument monumentales, comme 500 fois plus rapide que le tri rapide. Vous pouvez donc être des ordres de grandeur plus rapides que ce qui était supposément optimal simplement parce que vous n’êtes pas dans le cas général mais dans le cas de la supply chain. C’est quelque chose de très important, et je crois que c’est là que réside l’essentiel des résultats impressionnants que nous pouvons obtenir en exploitant les algorithmes pour la supply chain.
Je pense que cette perspective est erronée pour au moins deux raisons. Premièrement, comme nous l’avons vu, ce n’est pas nécessairement l’algorithme standard qui est intéressant. Nous avons vu qu’il existe un algorithme supposément optimal comme le tri rapide, mais si vous prenez le même problème du point de vue de la supply chain, vous pouvez réellement obtenir des accélérations massives. Il est donc primordial de connaître les algorithmes, ne serait-ce que pour être en mesure de revisiter les classiques et obtenir des accélérations massives simplement parce que vous n’êtes pas dans le cas général mais dans le cas de la supply chain.
La deuxième raison pour laquelle je pense que cette perspective est erronée est que les algorithmes sont très liés aux structures de données. Les structures de données sont des moyens d’organiser les données de manière à pouvoir les traiter plus efficacement. Ce qui est intéressant, c’est que toutes ces structures de données forment un vocabulaire en quelque sorte, et avoir accès à ce vocabulaire est essentiel pour être en mesure de décrire des situations de supply chain de manière à faciliter leur traduction en logiciel. Si vous commencez par une description en termes profanes, vous finissez généralement par des choses extrêmement difficiles à traduire en logiciel. Si vous attendez d’un ingénieur logiciel, qui ne connaît rien à la supply chain, qu’il implémente cette traduction pour vous, cela peut être une source de problèmes. C’est en réalité beaucoup plus facile si vous connaissez ce vocabulaire, afin de pouvoir directement utiliser les termes qui se prêtent facilement à la traduction des idées que vous avez en logiciel.
Passons en revue les structures de données les plus populaires et les plus simples. La première serait la liste. La liste peut être utilisée, par exemple, pour représenter un itinéraire de livraison, qui serait la séquence des livraisons à effectuer, avec une entrée par livraison. Vous pouvez énumérer l’itinéraire de livraison au fur et à mesure de son avancement. Une liste peut également représenter un flux de travail, qui est une séquence d’opérations nécessaires pour fabriquer un certain équipement, ou une chaîne de commandement, qui détermine qui est censé prendre certaines décisions.
De même, les arbres sont une autre structure de données omniprésente. Au fait, les arbres algorithmiques sont à l’envers, avec la racine en haut et les branches en bas. Les arbres vous permettent de décrire toutes sortes de hiérarchies, et les supply chains ont des hiérarchies partout. Par exemple, une nomenclature est un arbre ; vous avez un équipement que vous souhaitez fabriquer, et cet équipement est composé d’assemblages. Chaque assemblage est composé de sous-assemblages, et chaque sous-assemblage est composé de pièces. Si vous développez complètement la nomenclature, vous obtenez un arbre. De même, un catalogue de produits, où vous avez des familles de produits, des catégories de produits, des produits, des sous-catégories, etc., a très souvent une architecture de type arborescent. Un organigramme, avec le PDG en haut, les cadres supérieurs en dessous, et ainsi de suite, est également représenté par un arbre. La théorie algorithmique vous offre une multitude d’outils et de méthodes pour traiter les arbres et effectuer des opérations efficacement sur les arbres. Chaque fois que vous pouvez représenter des données sous forme d’arbre, vous disposez d’un arsenal complet de méthodes mathématiques pour travailler efficacement avec ces arbres. C’est pourquoi cela suscite un grand intérêt.
Maintenant, les graphes vous permettent de décrire toutes sortes de réseaux. Au fait, un graphe, au sens mathématique, est un ensemble de sommets et un ensemble d’arêtes, les arêtes reliant deux sommets entre eux. Le terme “graphe” peut être un peu trompeur car il n’a rien à voir avec les graphiques. Un graphe est simplement un objet mathématique, pas un dessin ou quoi que ce soit de graphique. Lorsque vous savez comment rechercher des graphes, vous verrez que les supply chains ont des graphes partout.
Quelques exemples : un assortiment dans un réseau de vente au détail, qui est fondamentalement un graphe biparti, relie les produits et les magasins. Si vous avez un programme de fidélité où vous enregistrez quel client a acheté quel produit au fil du temps, vous avez un autre graphe biparti reliant les clients et les produits. Dans l’après-vente automobile, où vous avez des réparations à effectuer, vous devez généralement utiliser une matrice de compatibilité qui vous indique la liste des pièces compatibles mécaniquement avec le véhicule d’intérêt. Cette matrice de compatibilité est essentiellement un graphe. Il existe une énorme quantité de littérature sur toutes sortes d’algorithmes qui vous permettent de travailler avec des graphes, il est donc très intéressant lorsque vous pouvez caractériser un problème comme étant soutenu par une structure de graphe car toutes les méthodes connues dans la littérature deviennent facilement disponibles.
Enfin, la dernière structure de données que je vais aborder aujourd’hui est la table de hachage. La table de hachage est essentiellement le couteau suisse des algorithmes. Ce n’est pas nouveau ; aucune des structures de données que j’ai présentées n’est récente selon les normes. La table de hachage est probablement la plus récente de toutes, datant des années 1950, donc ce n’est pas récent. Néanmoins, la table de hachage est une structure de données incroyablement utile. C’est un conteneur qui contient des paires de clés et de valeurs. L’idée est qu’avec ce conteneur, vous pouvez stocker beaucoup de données, et il vous offre des performances en O(1) pour la recherche, l’insertion et la suppression. Vous disposez d’un conteneur où vous pouvez, en temps constant, ajouter des données, vérifier si des données sont présentes ou non (en regardant la clé) et éventuellement supprimer des données. C’est très intéressant et utile. Les tables de hachage sont littéralement partout et sont largement utilisées à l’intérieur d’autres algorithmes.
Une chose que je soulignerai, et nous reviendrons sur ce point plus tard, c’est que les performances d’une table de hachage dépendent beaucoup des performances de la fonction de hachage que vous avez.
Maintenant, regardons les recettes magiques, et nous passerons complètement à une perspective différente. Les nombres magiques sont fondamentalement un anti-pattern. Dans la conférence précédente, celle sur les connaissances négatives pour la supply chain, nous avons discuté de la façon dont les anti-patterns commencent généralement avec une bonne intention mais se terminent par des conséquences imprévues qui annulent les avantages supposément apportés par la solution. Les nombres magiques sont un anti-pattern de programmation bien connu. Cet anti-pattern de programmation consiste à écrire du code parsemé de constantes qui semblent sortir de nulle part, rendant votre logiciel très difficile à maintenir. Lorsque vous avez des tonnes de constantes, il n’est pas clair pourquoi vous avez ces contraintes et comment elles ont été choisies.
Habituellement, lorsque vous voyez des nombres magiques dans un programme, il est préférable d’isoler toutes ces constantes dans un endroit où elles sont plus gérables. Cependant, il y a des situations où le choix soigneux de constantes fait quelque chose de complètement inattendu, et vous avez des avantages presque magiques, complètement involontaires, en utilisant des nombres qui semblent être tombés du ciel. C’est exactement de quoi traite l’algorithme très court que je présente ici.
En supply chain, très souvent, nous voulons être en mesure de réaliser une simulation d’une certaine sorte. Les simulations ou les processus de Monte Carlo sont l’un des trucs de base que vous pouvez utiliser dans une myriade de situations de supply chain. Cependant, les performances de votre simulation dépendent beaucoup de votre capacité à générer des nombres aléatoires. Pour générer des simulations, il y a généralement un degré de hasard généré impliqué, et donc vous avez besoin d’un algorithme pour générer ce hasard. En ce qui concerne les ordinateurs, il s’agit généralement de pseudo-aléatoire - ce n’est pas un vrai hasard ; c’est juste quelque chose qui ressemble à des nombres aléatoires et qui a les attributs statistiques de nombres aléatoires mais qui n’est pas réellement aléatoire.
La question devient alors : comment pouvez-vous générer efficacement des nombres aléatoires ? Il se trouve qu’il existe un algorithme appelé “Shift”, publié en 2003 par George Marsaglia, qui est assez impressionnant. Cet algorithme génère des nombres aléatoires de très haute qualité, créant une permutation complète de 2 à la puissance de 64 moins 1 bits. Il va circuler à travers toutes les combinaisons de 64 bits, moins une, avec zéro comme point fixe. Il le fait avec essentiellement six opérations : trois décalages binaires et trois opérations XOR (ou exclusif), qui sont des opérations bit à bit. Les décalages sont également des opérations bit à bit.
Ce que nous voyons, c’est qu’il y a trois nombres magiques au milieu de cela : 13, 7 et 17. Au fait, tous ces nombres sont des nombres premiers ; ce n’est pas un hasard. Il s’avère que si vous choisissez ces constantes très spécifiques, vous obtenez un excellent générateur de nombres aléatoires qui se trouve être super rapide. Quand je dis super rapide, je veux dire que vous pouvez littéralement générer 10 mégaoctets par seconde de nombres aléatoires. C’est absolument énorme. Si nous revenons à la conférence précédente, nous pouvons voir pourquoi cet algorithme est également si efficace. Non seulement nous n’avons que six instructions qui se mappent directement sur des instructions prises en charge nativement par le matériel informatique sous-jacent, comme le processeur, mais nous n’avons également aucune branche. Il n’y a aucun test, et cela signifie que cet algorithme, une fois exécuté, utilisera au maximum la capacité de pipelining du processeur car il n’y a pas de branchement. Nous pouvons littéralement exploiter au maximum la capacité de pipelining profond que nous avons dans un processeur moderne. C’est très intéressant.
La question est : pourrions-nous choisir d’autres nombres pour faire fonctionner cet algorithme ? La réponse est non. Il n’y a que quelques dizaines, voire une centaine de combinaisons différentes de nombres qui fonctionneraient réellement, et tous les autres vous donneront un générateur de nombres de très basse qualité. C’est là que c’est magique. Vous voyez, c’est une tendance récente dans le développement algorithmique de trouver quelque chose de complètement inattendu où vous trouvez une constante semi-magique qui vous donne des avantages complètement non intentionnels en mélangeant des opérations binaires très inattendues d’une certaine sorte. La génération de nombres aléatoires est d’une importance capitale pour la supply chain.
Mais, comme je le disais, les tables de hachage sont partout, et il est également très intéressant d’avoir une fonction de hachage générique super performante. Est-ce que ça existe ? Oui. Il existe des classes entières de fonctions de hachage disponibles depuis des décennies, mais en 2019, un autre algorithme a été publié qui offre des performances exceptionnelles. Celui que vous pouvez voir à l’écran s’appelle “WyHash” par Wang Yi. Essentiellement, vous pouvez voir que la structure est très similaire à l’algorithme XORShift. C’est un algorithme qui n’a pas de branche, comme XORShift, et il utilise également l’opération XOR. L’algorithme utilise six instructions : quatre opérations XOR et deux opérations Multiply-No-Flags.
Multiply-No-Flags est simplement la multiplication classique entre deux entiers de 64 bits, et en résultat, vous collectez les 64 bits de poids fort et les 64 bits de poids faible. Il s’agit d’une instruction réelle disponible dans les processeurs modernes, implémentée au niveau matériel, donc elle compte comme une seule instruction informatique. Nous en avons deux. Encore une fois, nous avons trois nombres magiques, écrits sous forme hexadécimale. Au fait, ce sont des nombres premiers, encore une fois, complètement semi-magiques. Si vous appliquez cet algorithme, vous obtenez une fonction de hachage absolument excellente et non cryptographique qui fonctionne presque à la vitesse de memcpy. C’est très rapide et d’un intérêt primordial.
Maintenant, passons à quelque chose de complètement différent. Le succès de l’apprentissage profond et de nombreuses autres méthodes modernes d’apprentissage automatique repose sur quelques idées algorithmiques clés sur les problèmes qui peuvent être massivement accélérés par du matériel informatique dédié. C’est ce dont j’ai parlé dans ma précédente conférence lorsque je parlais de processeurs avec des instructions super-scalaires et, si vous en voulez plus, des GPU et même des TPU. Revisitons cette idée pour voir comment tout cela a émergé de manière plutôt chaotique. Cependant, je pense que les idées pertinentes se sont cristallisées au cours des dernières années. Pour comprendre où nous en sommes aujourd’hui, nous devons revenir à la notation d’Einstein, qui a été introduite il y a un peu plus d’un siècle par Albert Einstein dans l’un de ses articles. L’intuition est simple : vous avez une expression y qui est une somme de i égal à 1 à i égal à 3 de c_y fois x_y. Nous avons des expressions écrites comme ça, et l’intuition de la notation d’Einstein est de dire, dans ce genre de situation, nous devrions l’écrire en omettant complètement la sommation. En termes de logiciel, la sommation serait une boucle for. L’idée est d’omettre complètement la sommation et de dire que par convention, nous faisons la somme sur tous les indices pour la variable i qui a un sens.
Cette simple intuition donne deux résultats très surprenants mais positifs. Le premier est la correction de la conception. Lorsque nous écrivons explicitement la somme, nous risquons de ne pas avoir les bons indices, ce qui peut entraîner des erreurs de dépassement d’indice dans le logiciel. En supprimant la sommation explicite et en déclarant que nous prendrons toutes les positions d’index valides par définition, nous adoptons une approche correcte par conception. Cela seul est d’un intérêt primordial et est lié à la programmation par tableau, un paradigme de programmation que j’ai brièvement abordé dans l’une de mes conférences précédentes.
La deuxième idée, qui est plus récente et d’un grand intérêt de nos jours, est que si vous pouvez formuler votre problème de manière à ce que la notation d’Einstein s’applique, votre problème peut bénéficier d’une accélération matérielle massive en pratique. C’est un élément révolutionnaire.
Pour comprendre pourquoi, il existe un article très intéressant intitulé “Tensor Comprehensions” publié en 2018 par l’équipe de recherche de Facebook. Ils ont introduit la notion de “tensor comprehensions”. Tout d’abord, permettez-moi de définir les deux mots. Dans le domaine de l’informatique, un tenseur est essentiellement une matrice multidimensionnelle (en physique, les tenseurs sont complètement différents). Une valeur scalaire est un tenseur de dimension zéro, un vecteur est un tenseur de dimension un, une matrice est un tenseur de dimension deux, et vous pouvez avoir des tenseurs avec des dimensions encore plus élevées. Les tenseurs sont des objets dotés de propriétés semblables à des tableaux.
La compréhension est quelque chose qui ressemble un peu à une algèbre avec les quatre opérations de base - plus, moins, multiplier et diviser - ainsi que d’autres opérations. Elle est plus étendue que l’algèbre arithmétique régulière ; c’est pourquoi ils ont une compréhension des tenseurs au lieu d’une algèbre des tenseurs. Elle est plus complète mais moins expressive qu’un langage de programmation complet. Lorsque vous avez une compréhension, elle est plus restrictive qu’un langage de programmation complet où vous pouvez faire ce que vous voulez.
L’idée est que si vous regardez la fonction MV (définition de MV), c’est fondamentalement une fonction, et MV signifie multiplication matrice-vecteur. Dans ce cas, il s’agit d’une multiplication matrice-vecteur, et cette fonction effectue essentiellement une multiplication entre la matrice A et le vecteur X. Nous voyons dans cette définition que la notation d’Einstein est en jeu : nous écrivons C_i = A_ik * X_k. Quelles valeurs devons-nous choisir pour i et k ? La réponse est toutes les combinaisons valides pour ces variables qui sont des indices. Nous prenons toutes les valeurs d’indices valides, faisons la somme, et en pratique, cela nous donne une multiplication matrice-vecteur.
En bas de l’écran, vous pouvez voir la même méthode MV réécrite avec des boucles for, en spécifiant explicitement les plages de valeurs. La réalisation clé de l’équipe de recherche de Facebook est que chaque fois que vous pouvez écrire un programme avec cette syntaxe de compréhension des tenseurs, ils ont développé un compilateur qui vous permet de bénéficier largement de l’accélération matérielle en utilisant des GPU. Fondamentalement, ils vous permettent d’accélérer n’importe quel programme que vous pouvez écrire avec cette syntaxe de compréhension des tenseurs. Chaque fois que vous pouvez écrire un programme sous cette forme, vous bénéficierez d’une accélération matérielle massive, et nous parlons de quelque chose qui sera deux ordres de grandeur plus rapide qu’un processeur classique. C’est un résultat stupéfiant en soi.
Maintenant, voyons ce que nous pouvons faire d’un point de vue de la supply chain avec cette approche. Un intérêt clé pour la pratique moderne de la supply chain est la prévision probabiliste. La prévision probabiliste, que j’ai abordée dans une conférence précédente, est l’idée que vous n’allez pas avoir une prévision ponctuelle, mais plutôt vous allez prévoir toutes les différentes probabilités pour une variable d’intérêt. Prenons par exemple une prévision de délai d’approvisionnement. Vous voulez prévoir votre délai d’approvisionnement et avoir une prévision probabiliste du délai d’approvisionnement.
Maintenant, disons que votre délai d’approvisionnement peut être décomposé en délai de fabrication et en délai de transport. En réalité, vous avez très probablement une prévision probabiliste pour le délai de fabrication, qui sera une variable aléatoire discrète vous donnant la probabilité d’observer un délai d’un jour, deux jours, trois jours, quatre jours, etc. Vous pouvez le considérer comme un grand histogramme qui vous donne les probabilités d’observer cette durée pour le délai de fabrication. Ensuite, vous allez avoir un processus similaire pour le délai de transport, avec une autre variable aléatoire discrète fournissant une prévision probabiliste.
Maintenant, vous voulez calculer le délai d’approvisionnement total. Si les délais d’approvisionnement prévus étaient des nombres, vous feriez simplement une addition simple. Cependant, les deux délais d’approvisionnement prévus ne sont pas des nombres ; ce sont des distributions de probabilité. Nous devons donc combiner ces deux distributions de probabilité pour obtenir une troisième distribution de probabilité, qui est la distribution de probabilité pour le délai d’approvisionnement total. Il s’avère que si nous faisons l’hypothèse que les deux délais, le délai de fabrication et le délai de transport, sont indépendants, l’opération que nous pouvons effectuer pour réaliser cette sommation de variables aléatoires est simplement une convolution unidimensionnelle. Cela peut sembler complexe, mais ce n’est pas vraiment le cas. Ce que j’ai implémenté, et ce que vous pouvez voir à l’écran, c’est l’implémentation d’une convolution unidimensionnelle entre un vecteur qui représente l’histogramme des probabilités du délai de fabrication (A) et l’histogramme associé aux probabilités du délai de transport (B). Le résultat est le temps total, qui est la somme de ces délais d’approvisionnement probabilistes. Si vous utilisez la notation de compréhension des tenseurs, cela peut être écrit dans un algorithme très compact d’une seule ligne.
Maintenant, si nous revenons à la notation Big O que j’ai introduite plus tôt dans cette conférence, nous voyons que nous avons fondamentalement un algorithme quadratique. C’est Big O de N^2, avec N étant la taille caractéristique des tableaux pour A et B. Comme je l’ai mentionné, les performances quadratiques sont un point faible des problèmes de prévision. Alors, que pouvons-nous faire pour résoudre ce problème ? Tout d’abord, nous devons considérer que c’est un problème de supply chain, et nous avons la loi des petits nombres que nous pouvons utiliser à notre avantage. Comme nous l’avons discuté dans la conférence précédente, les supply chains sont principalement basées sur de petits nombres. Si nous regardons les délais d’approvisionnement, nous pouvons raisonnablement supposer que ces délais d’approvisionnement seront plus petits que, disons, 400 jours. C’est déjà assez long pour cet histogramme de probabilité.
Donc, ce qui nous reste, c’est un Big O de N^2, mais avec N plus petit que 400. 400 peut être assez grand, car 400 fois 400, c’est 160 000. C’est un nombre significatif, et rappelez-vous que l’ajout à cette distribution de probabilité est une opération très basique. Dès que nous commençons à faire des prévisions probabilistes, nous voulons combiner nos prévisions de différentes manières, et nous finirons très probablement par faire des millions de ces convolutions, simplement parce que fondamentalement, ces convolutions ne sont rien d’autre qu’une addition glorifiée projetée dans le domaine des variables aléatoires. Ainsi, même si nous avons contraint N à être inférieur à 400, il est très intéressant d’apporter une accélération matérielle à la table, et c’est précisément ce que nous pouvons réaliser avec la compréhension des tenseurs.
La chose clé à retenir est que dès que vous pouvez écrire cet algorithme, vous voulez tirer parti de ce que vous savez sur les concepts de la supply chain pour clarifier les hypothèses applicables, puis tirer parti des outils que vous avez pour obtenir une accélération matérielle.
Maintenant, parlons des techniques méta. Les techniques méta sont d’un grand intérêt car elles peuvent être superposées aux algorithmes existants, et donc, si vous avez un algorithme, il y a une chance que vous puissiez utiliser l’une de ces techniques méta pour améliorer ses performances. La première idée clé est la compression, simplement parce que des données plus petites signifient un traitement plus rapide. Comme nous l’avons vu dans la conférence précédente, nous n’avons pas un accès uniforme à la mémoire. Si vous voulez accéder à plus de données, vous devez accéder à différents types de mémoire physique, et à mesure que la mémoire augmente, vous accédez à différents types de mémoire qui sont beaucoup moins efficaces. Le cache L1 à l’intérieur du processeur est très petit, environ 64 kilo-octets, mais il est très rapide. La RAM, ou mémoire principale, est plusieurs centaines de fois plus lente que ce petit cache, mais vous pouvez avoir littéralement un téraoctet de RAM. Ainsi, il est très intéressant de s’assurer que vos données sont aussi petites que possible, car cela rendra presque invariablement vos algorithmes plus rapides. Il existe une série d’astuces que vous pouvez utiliser à cet égard.
Tout d’abord, vous pouvez nettoyer et organiser vos données. Cela relève du domaine des logiciels d’entreprise. Lorsque vous avez un algorithme qui s’exécute sur des données, il y a souvent beaucoup de données inutilisées qui ne contribuent pas à la solution d’intérêt. Il est essentiel de veiller à ce que vous ne vous retrouviez pas avec les données d’intérêt entrelacées avec des données qui se trouvent être ignorées.
La deuxième idée est l’emballage de bits. Il y a de nombreuses situations où vous pouvez emballer certains indicateurs à l’intérieur d’autres éléments, tels que des pointeurs. Vous pouvez avoir un pointeur de 64 bits, mais il est très rare que vous ayez réellement besoin d’une plage d’adresses de 64 bits dans toute son étendue. Vous pouvez sacrifier quelques bits de votre pointeur pour injecter certains indicateurs, ce qui vous permet de réduire votre volume de données avec presque aucune perte de performance.
De plus, vous pouvez ajuster votre précision. Avez-vous besoin de 64 bits de précision en virgule flottante dans la supply chain ? Il est très rare que vous ayez réellement besoin de cette précision. Habituellement, 32 bits de précision suffisent, et il y a même de nombreuses situations où 16 bits de précision sont suffisants. Vous pourriez penser que la réduction de la précision n’est pas significative, mais fréquemment, lorsque vous pouvez diviser la taille des données par un facteur de deux, vous ne accélérez pas simplement votre algorithme d’un facteur de 2 ; vous l’accélérez littéralement d’un facteur de 10. L’emballage des données offre des avantages complètement non linéaires en termes de vitesse d’exécution.
Enfin, vous avez le codage d’entropie, qui est essentiellement de la compression. Cependant, vous ne voulez pas nécessairement utiliser des algorithmes aussi efficaces pour compresser que, disons, l’algorithme utilisé pour une archive ZIP. Vous voulez quelque chose qui pourrait être un peu moins efficace en termes de compression mais beaucoup plus rapide en exécution.
La compression repose fondamentalement sur l’idée que vous pouvez échanger un peu d’utilisation supplémentaire du processeur pour diminuer la pression sur la mémoire, et dans presque toutes les situations, c’est le tour de passe-passe qui intéresse.
Cependant, il y a des situations où vous voulez faire exactement le contraire - échanger de la mémoire pour réduire considérablement votre consommation de CPU. C’est précisément ce que vous faites avec le tour de passe-passe de la mémorisation. La mémorisation repose fondamentalement sur l’idée que si une fonction est appelée plusieurs fois au cours de l’exécution de votre solution, et que la même fonction est appelée avec les mêmes entrées, vous n’avez pas besoin de recalculer la fonction. Vous pouvez enregistrer le résultat, le mettre de côté (par exemple, dans une table de hachage), et lorsque vous revisitez la même fonction, vous pourrez vérifier si la table de hachage contient déjà une clé associée à l’entrée ou si la table de hachage contient déjà le résultat car il a été précalculé. Si la fonction que vous mémorisez est très coûteuse, vous pouvez obtenir une accélération massive. Là où cela devient très intéressant, c’est lorsque vous commencez à utiliser la mémorisation non pas avec la mémoire principale, comme nous l’avons vu dans la conférence précédente, la DRAM est très coûteuse. Cela devient très intéressant lorsque vous commencez à mettre vos résultats sur disque ou SSD, qui sont bon marché et abondants. L’idée est que vous pouvez échanger des SSD en échange d’une réduction de la pression sur le CPU, ce qui est, d’une certaine manière, exactement l’opposé de la compression que je viens de décrire.
La dernière méta-technique est l’immuabilité. Les structures de données immuables sont fondamentalement des structures de données qui ne sont jamais modifiées. L’idée est que les modifications sont superposées. Par exemple, avec une table de hachage immuable, lorsque vous ajoutez un élément, vous allez retourner une nouvelle table de hachage qui contient tout dans l’ancienne table de hachage plus le nouvel élément. La manière très naïve de le faire est de faire une copie complète de la structure de données et de retourner la copie entière ; cependant, c’est très inefficace. L’idée clé avec les structures de données immuables est que lorsque vous modifiez la structure de données, vous retournez une nouvelle structure de données qui implémente uniquement le changement, mais cette nouvelle structure de données recycle toutes les parties de l’ancienne structure de données qui n’ont pas été modifiées.
Presque toutes les structures de données classiques, telles que les listes, les arbres, les graphes et les tables de hachage, ont leurs homologues immuables. Dans de nombreuses situations, il est très intéressant de les utiliser. Au fait, il existe des langages de programmation modernes qui sont allés complètement dans l’immuabilité, comme Clojure, par exemple, pour ceux d’entre vous qui pourraient être familiers avec ce langage de programmation.
Pourquoi est-ce très intéressant ? Tout d’abord, parce que cela simplifie énormément la parallélisation des algorithmes. Comme nous l’avons vu dans la conférence précédente, il n’est pas possible de trouver un processeur qui fonctionne à 100 GHz pour les processeurs d’ordinateurs de bureau généraux. Ce que vous pouvez trouver, cependant, c’est une machine avec 50 cœurs, chaque cœur fonctionnant à 2 GHz. Si vous voulez profiter de ces nombreux cœurs, vous devez paralléliser votre exécution, et alors votre parallélisation est exposée à des bugs très méchants appelés conditions de concurrence. Il devient très difficile de comprendre si l’algorithme que vous avez écrit est correct ou non, car vous pouvez avoir plusieurs processeurs qui, en même temps, essaient d’écrire sur la même zone de mémoire de l’ordinateur.
Cependant, si vous avez des structures de données immuables, cela ne se produit jamais par conception, simplement parce qu’une fois qu’une structure de données est présentée, elle ne changera jamais - seule une nouvelle structure de données émergera. Ainsi, vous pouvez obtenir une accélération de performance massive avec le chemin immuable simplement parce que vous pouvez plus facilement implémenter des versions parallèles de vos algorithmes. Gardez à l’esprit que généralement, le goulot d’étranglement pour implémenter une accélération algorithmique est le temps nécessaire pour réellement implémenter les algorithmes. Si vous avez quelque chose qui, par conception, vous permet d’appliquer une sorte de principe de concurrence sans crainte, vous pouvez réellement déployer des accélérations algorithmiques beaucoup plus rapidement, avec moins de ressources en termes du nombre de programmeurs impliqués. Un autre avantage important des structures de données immuables est qu’elles facilitent grandement le débogage. Lorsque vous modifiez de manière destructive une structure de données et rencontrez un bug, il peut être très difficile de comprendre comment vous en êtes arrivé là. Avec un débogueur, il peut être assez désagréable de localiser le problème. La chose intéressante avec les structures de données immuables est que les modifications sont non destructives, vous pouvez donc voir la version précédente de votre structure de données et comprendre plus facilement comment vous en êtes arrivé au point où vous rencontrez un comportement incorrect.
En conclusion, de meilleurs algorithmes peuvent sembler être des super pouvoirs. Avec de meilleurs algorithmes, vous obtenez plus des mêmes ressources informatiques, et ces avantages sont indéfinis. C’est un effort ponctuel, et ensuite vous avez un avantage indéfini car vous avez accès à des capacités de calcul supérieures, en considérant la même quantité de ressources informatiques consacrées à un problème d’intérêt de la chaîne d’approvisionnement donnée. Je crois que cette perspective offre des opportunités d’améliorations massives dans la gestion de la chaîne d’approvisionnement.
Si nous regardons un domaine complètement différent, comme les jeux vidéo, ils ont établi leurs propres traditions algorithmiques et découvertes dédiées à l’expérience de jeu. Les graphismes époustouflants que vous rencontrez avec les jeux vidéo modernes sont le produit d’une communauté qui a passé des décennies à repenser l’ensemble de la pile algorithmique pour maximiser la qualité de l’expérience de jeu. La perspective dans les jeux est de ne pas avoir un modèle 3D qui soit correct d’un point de vue physique ou scientifique, mais de maximiser la qualité perçue en termes d’expérience graphique pour le joueur, et ils ont peaufiné les algorithmes pour obtenir des résultats époustouflants.
Je crois que ce genre de travail n’a pratiquement pas commencé pour les chaînes d’approvisionnement. Les logiciels de chaîne d’approvisionnement d’entreprise sont bloqués, et à mon avis, nous n’utilisons même pas 1% de ce que le matériel informatique moderne peut faire pour nous. La plupart des opportunités sont à venir et peuvent être saisies grâce aux algorithmes, pas seulement aux algorithmes de chaîne d’approvisionnement comme les algorithmes de routage des véhicules, mais en revisitant les algorithmes classiques d’un point de vue de la chaîne d’approvisionnement pour obtenir des accélérations massives en cours de route.
Maintenant, je vais jeter un coup d’œil aux questions.
Question : Vous avez parlé des spécificités de la chaîne d’approvisionnement, comme les petits nombres. Lorsque nous savons à l’avance que nous avons de petits nombres dans nos décisions potentielles, quel genre de simplification cela apporte-t-il ? Par exemple, lorsque nous savons que nous pouvons commander au maximum un ou deux conteneurs, pouvez-vous penser à des exemples concrets de la manière dont cela influencerait le niveau de granularité des prévisions holistiques qui seront utilisées pour calculer la fonction de récompense des stocks ?
Tout d’abord, tout ce que j’ai présenté aujourd’hui est en production chez Lokad. Toutes ces idées, d’une manière ou d’une autre, sont très applicables à la chaîne d’approvisionnement car elles sont en production chez Lokad. Vous devez réaliser que ce que vous obtenez des logiciels modernes n’a pas été optimisé pour tirer le meilleur parti du matériel informatique. Pensez simplement qu’aujourd’hui, nous avons des ordinateurs qui sont mille fois plus performants que ceux que nous avions il y a quelques décennies. Fonctionnent-ils mille fois plus vite ? Non. Peuvent-ils résoudre des problèmes beaucoup plus complexes que ce que nous avions il y a quelques décennies ? Non. Ne sous-estimez donc pas le fait qu’il existe de très grandes possibilités d’amélioration.
Le tri par compartiments que j’ai présenté dans cette leçon est un exemple simple. Vous avez des opérations de tri partout dans la chaîne d’approvisionnement, et à ma connaissance, il est très rare que vous ayez un logiciel d’entreprise qui tire parti d’algorithmes spécialisés adaptés aux situations de la chaîne d’approvisionnement. Maintenant, lorsque nous savons que nous avons un ou deux conteneurs, en profitons-nous chez Lokad ? Oui, tout le temps, et il existe des tonnes d’astuces qui peuvent être mises en œuvre à ce niveau.
Les astuces se trouvent généralement à un niveau inférieur et les avantages se répercuteront sur la solution globale. Vous devez réfléchir à la décomposition des problèmes de remplissage de conteneurs en toutes leurs sous-parties. Vous pouvez obtenir des avantages en appliquant les idées et les astuces que j’ai présentées aujourd’hui au niveau inférieur.
Par exemple, de quelle précision numérique avez-vous besoin si nous parlons de conteneurs ? Peut-être que des nombres sur 16 bits avec seulement 16 bits de précision suffiraient. Cela rend les données plus petites. Combien de produits distincts commandons-nous ? Peut-être que nous ne commandons que quelques milliers de produits distincts, nous pouvons donc utiliser le tri par compartiments. La distribution de probabilité est un nombre inférieur et plus petit, donc en théorie, nous avons des histogrammes qui peuvent aller de zéro unité, une unité, trois unités, jusqu’à l’infini, mais allons-nous jusqu’à l’infini ? Non. Peut-être pouvons-nous faire quelques hypothèses intelligentes sur le fait qu’il est très rare que nous ayons un histogramme où nous dépassons 1 000 unités. Lorsque nous avons cela, nous pouvons faire une approximation. Nous n’avons pas nécessairement besoin d’une précision de 2 unités si nous traitons un conteneur qui contient 1 000 unités. Nous pouvons faire une approximation et avoir un histogramme avec des compartiments plus grands et ce genre de choses. Il ne s’agit pas tant, je dirais, d’introduire des principes algorithmiques comme la compréhension des tenseurs, qui sont incroyables car ils simplifient tout de manière très cool. Cependant, la plupart des accélérations algorithmiques se traduisent par un algorithme plus rapide mais légèrement plus compliqué. Ce n’est pas nécessairement plus simple car généralement, l’algorithme le plus simple est aussi inefficace. Un algorithme plus approprié pour un cas peut être un peu plus long à écrire et plus complexe, mais à la fin, il s’exécutera plus rapidement. Ce n’est pas toujours le cas, comme nous l’avons vu avec les recettes magiques, mais ce que je voulais montrer, c’est que nous devons revoir les blocs de construction fondamentaux de ce que nous faisons pour construire réellement des logiciels d’entreprise.
Question : Dans quelle mesure ces idées sont-elles mises en œuvre chez les fournisseurs de ERP, les APS et les meilleurs de leur catégorie comme GTA ?
La chose intéressante est que la plupart de ces idées sont fondamentalement incompatibles avec les logiciels transactionnels. La plupart des logiciels d’entreprise sont construits autour d’une base de données transactionnelle, et tout passe par cette base de données. Cette base de données n’est pas spécifique à la supply chain ; c’est une base de données générique censée pouvoir gérer toutes les situations possibles, de la finance à l’informatique scientifique, en passant par les dossiers médicaux, et bien plus encore.
Le problème est que si le logiciel que vous regardez a une base de données transactionnelle au cœur, alors les idées que j’ai proposées ne peuvent pas être mises en œuvre par conception. C’est un peu la fin du jeu. Si vous regardez les jeux vidéo, combien de jeux vidéo sont construits sur une base de données transactionnelle ? La réponse est zéro. Pourquoi ? Parce que vous ne pouvez pas avoir de bonnes performances graphiques mises en œuvre sur une base de données transactionnelle. Vous ne pouvez pas faire de graphismes informatiques dans une base de données transactionnelle.
Une base de données transactionnelle est très bien ; elle vous donne la transactionnalité, mais elle vous enferme dans un monde où presque toutes les accélérations algorithmiques auxquelles vous pouvez penser ne peuvent tout simplement pas s’appliquer. Je crois que lorsque nous commençons à réfléchir à l’APS, il n’y a rien de très avancé dans ces systèmes. Ils sont bloqués dans le passé depuis des décennies maintenant, et ils sont bloqués parce qu’au cœur de leur conception, ils sont entièrement conçus autour d’une base de données transactionnelle qui les empêche d’appliquer les idées qui ont émergé du domaine des algorithmes au cours des probablement quatre dernières décennies.
C’est là que réside le problème dans le domaine des logiciels d’entreprise. Les décisions de conception que vous prenez dans le premier mois de la conception de votre produit vous hanteront pendant des décennies, essentiellement jusqu’à la fin des temps. Vous ne pouvez pas mettre à niveau une fois que vous avez décidé d’une conception spécifique pour votre produit ; vous êtes coincé avec elle. Tout comme vous ne pouvez pas simplement ré-ingénier une voiture pour en faire une voiture électrique, si vous voulez avoir une très bonne voiture électrique, vous ré-ingéniez entièrement la voiture autour de l’idée que le moteur de propulsion sera électrique. Il ne s’agit pas simplement de remplacer le moteur et de dire : “Voici une voiture électrique.” Ça ne fonctionne pas comme ça. Il s’agit de l’un de ces principes de conception fondamentaux où une fois que vous vous êtes engagé à produire une voiture électrique, vous devez repenser tout autour du moteur pour que cela corresponde bien. Malheureusement, les ERP et les APS qui sont très centrés sur les bases de données ne peuvent tout simplement pas utiliser ces idées, je le crains. Il est toujours possible d’avoir une bulle isolée où vous bénéficiez de ces astuces, mais cela va être un ajout boulonné ; cela ne fera jamais partie intégrante.
En ce qui concerne les capacités impressionnantes de Blue Yonder, veuillez me pardonner, car Lokad est un concurrent direct de Blue Yonder, et il m’est difficile d’être complètement impartial. Sur le marché des logiciels d’entreprise, vous devez faire des affirmations ridiculement audacieuses pour rester compétitif. Je ne suis pas convaincu qu’il y ait la moindre substance à l’une de ces affirmations. Je remets en question le postulat selon lequel quiconque sur ce marché a quelque chose qui pourrait être qualifié d’impressionnant.
Si vous voulez voir quelque chose de stupéfiant et d’ultra-impressionnant, regardez la dernière démo de l’Unreal Engine ou les algorithmes de jeux vidéo spécialisés. Considérez les graphismes informatiques sur le matériel de la prochaine génération de la PlayStation 5 ; c’est absolument stupéfiant. Avons-nous quelque chose de comparable en termes de réalisation technologique dans le domaine des logiciels d’entreprise ? En ce qui concerne Lokad, j’ai un avis très partial, mais en regardant le marché de manière plus générale, je vois un océan de personnes qui ont essayé de maximiser les bases de données relationnelles depuis des décennies. Parfois, ils apportent d’autres types de bases de données, comme les bases de données graphiques, mais cela passe complètement à côté des idées que j’ai présentées. Cela ne fournit rien de concret pour apporter de la valeur au monde de la supply chain.
Le message clé ici pour le public est qu’il s’agit d’une question de conception. Nous devons nous assurer que les décisions initiales prises lors de la conception de votre logiciel d’entreprise ne sont pas du genre à empêcher, par conception, l’utilisation de ces techniques dès le départ.
La prochaine conférence aura lieu dans trois semaines, le mercredi à 15 heures, heure de Paris. Ce sera le 13 juin et nous revisiterons le troisième chapitre, qui concerne le personnel de la supply chain, les traits de personnalité surprenants et les entreprises fictives. La prochaine fois, nous parlerons de fromage. À bientôt !
