PROGRAMMING PARADIGMS FOR SUPPLY CHAIN (RÉSUMÉ DE LA CONFÉRENCE 1.4)

problèmes de supply chain sont redoutables et tenter de les aborder sans outils de programmation appropriés - dans le contexte d’une entreprise à grande échelle - s’avère être une expérience d’apprentissage invariablement coûteuse. Optimiser efficacement la supply chain - un réseau dispersé de complexités physiques et abstraites – nécessite une suite de paradigmes de programmation. Ces paradigmes sont essentiels à l’identification, à la prise en compte et à la résolution de la vaste et variée gamme de problèmes inhérents à la supply chain.

Regardez la Conférence

Analyse statique

Il n’est pas nécessaire d’être programmeur pour penser comme tel, et l’analyse appropriée des problèmes de supply chain se fait mieux avec une mentalité de programmation, et pas seulement avec des outils de programmation. Les solutions logicielles traditionnelles (telles que les ERP) sont conçues de telle manière que les problèmes sont traités à l’exécution plutôt qu’à la compilation¹.

C’est la différence entre une solution réactive et une solution proactive. Cette distinction est cruciale car les solutions réactives tendent à être beaucoup plus coûteuses que les solutions proactives, tant en termes financiers qu’en termes de bande passante. Ces coûts largement évitables sont précisément ce qu’une mentalité de programmation vise à éviter, et l’analyse statique en est l’expression.

L’analyse statique consiste à examiner un programme (dans ce cas, l’optimisation) sans l’exécuter, afin d’identifier d’éventuels problèmes avant qu’ils n’aient un impact sur la production. Lokad aborde l’analyse statique via Envision, son langage spécifique au domaine (DSL). Cela permet d’identifier et de corriger les erreurs au niveau de la conception (dans le langage de programmation) aussi rapidement et commodément que possible.

Considérez une entreprise en train de construire un entrepôt. On n’érige pas l’entrepôt puis on en envisage ensuite l’agencement. Au contraire, l’agencement stratégique des allées, des rayonnages et des quais de chargement est envisagé à l’avance afin d’identifier d’éventuels goulots d’étranglement avant la construction. Cela permet une conception optimale - et donc un flux optimal - au sein du futur entrepôt. Cette minutieuse élaboration de plans est analogue à l’analyse statique que Lokad réalise via Envision.

L’analyse statique, telle que décrite ici, modéliserait la programmation sous-jacente de l’optimisation et identifierait tout comportement potentiellement antagoniste dans la recette avant son installation. Ces tendances antagonistes pourraient inclure un bug entraînant la commande accidentelle de bien plus de stocks que nécessaire. Par conséquent, de tels bugs seraient éliminés du code avant d’avoir la chance de provoquer le chaos.

Programmation par tableau

Dans l’optimisation de la supply chain, le respect des délais est essentiel. Par exemple, dans une chaîne de distribution, les données doivent être consolidées, optimisées et transmises au système de gestion d’entrepôt dans un délai de 60 minutes. Si les calculs prennent trop de temps, l’exécution de l’ensemble de la supply chain peut être compromise. La programmation par tableau permet de pallier ce problème en éliminant certaines classes d’erreurs de programmation et en garantissant la durée des calculs, fournissant ainsi aux praticiens de la supply chain un horizon temporel prévisible pour le traitement des données.

Également connue sous le nom de programmation sur data frame, cette approche permet d’effectuer des opérations directement sur des tableaux de données, plutôt que sur des données isolées. Lokad y parvient en exploitant Envision, son DSL. La programmation par tableau peut simplifier la manipulation et l’analyse des données, notamment en effectuant des opérations sur des colonnes entières de données plutôt que sur des entrées individuelles au sein de chaque tableau. Cela augmente considérablement l’efficacité de l’analyse et réduit ainsi les risques de bugs dans la programmation.

Considérons un gestionnaire d’entrepôt qui dispose de deux listes : la Liste A représente les niveaux de stocks actuels, et la Liste B représente les arrivages pour les produits de la Liste A. Plutôt que de passer en revue chaque produit un par un et d’ajouter manuellement les arrivages (Liste B) aux niveaux de stocks actuels (Liste A), une méthode plus efficace serait de traiter les deux listes simultanément, permettant ainsi de mettre à jour les niveaux de stocks pour tous les produits en un seul mouvement. Cela permet d’économiser à la fois du temps et des efforts, et constitue essentiellement l’objectif de la programmation par tableau².

En réalité, la programmation par tableau facilite la parallélisation et la distribution du calcul des vastes quantités de données impliquées dans l’optimisation de la supply chain. En répartissant le calcul sur plusieurs machines, les coûts peuvent être réduits et les temps d’exécution raccourcis.

Miscibilité matérielle

Un des principaux goulets d’étranglement dans l’optimisation de la supply chain est le nombre limité de supply chain scientists. Ces scientifiques sont responsables de la création de recettes numériques qui prennent en compte les stratégies des clients, ainsi que les machinations antagonistes des concurrents, afin de produire des informations exploitables.

Non seulement il peut être difficile de recruter ces experts, mais une fois qu’ils sont en poste, ils doivent souvent surmonter plusieurs obstacles matériels qui les séparent de l’exécution rapide de leurs tâches. La miscibilité matérielle - la capacité de divers composants d’un système à s’harmoniser et à fonctionner ensemble - est cruciale pour éliminer ces obstacles. Trois ressources informatiques fondamentales sont considérées ici :

• Compute: La puissance de traitement d’un ordinateur, fournie soit par le CPU soit par le GPU.
• Memory: La capacité de stockage de données d’un ordinateur, hébergée via la RAM ou la ROM.
• Bandwidth: Le débit maximal auquel l’information (données) peut être transférée entre différentes parties d’un ordinateur, ou à travers un réseau d’ordinateurs.

Le traitement de grands ensembles de données est généralement un processus chronophage, ce qui entraîne une productivité moindre pendant que les ingénieurs attendent l’exécution des tâches. Dans une optimisation de la supply chain, on pourrait stocker des extraits de code (représentant des étapes intermédiaires de calcul de routine) sur des disques SSD. Cette simple initiative permet aux supply chain scientists d’exécuter plus rapidement des scripts similaires comportant seulement de légères modifications, augmentant ainsi significativement la productivité.

Dans l’exemple ci-dessus, on a exploité une astuce mémoire économique pour réduire la charge de calcul : le système constate que le script en cours de traitement est presque identique aux précédents, ce qui permet d’exécuter le calcul en quelques secondes plutôt qu’en dizaines de minutes.

Ce genre de miscibilité matérielle permet aux entreprises d’extraire la valeur maximale de leurs investissements.

Programmation probabiliste

Il existe une infinité de résultats futurs possibles, ils ne sont tout simplement pas tous également probables. Compte tenu de cette incertitude irréductible, l’(ou les) outil(s) de programmation doivent adopter un paradigme de prévision probabiliste . Bien qu’Excel ait historiquement été le pilier de nombreuses supply chains, il ne peut pas être déployé à grande échelle avec des prévisions probabilistes, car ce type de prévision nécessite la capacité de traiter l’algèbre des variables aléatoires³.

En bref, Excel est principalement conçu pour des données déterministes (c’est-à-dire des valeurs fixes, comme des nombres entiers statiques). Bien qu’il puisse être modifié pour effectuer certaines fonctions de probabilité, il manque de la fonctionnalité avancée - ainsi que de la flexibilité et de l’expressivité globales - requises pour gérer la manipulation complexe des variables aléatoires que l’on rencontre dans la prévision probabiliste de la demande. Au contraire, un langage de programmation probabiliste - tel qu’Envision - est mieux adapté pour représenter et traiter les incertitudes rencontrées dans la supply chain.

Considérons un magasin de pièces automobiles de rechange vendant des plaquettes de frein. Dans ce scénario hypothétique, les clients doivent acheter des plaquettes de frein par lots de 2 ou 4, et le magasin doit prendre en compte cette incertitude lors de la prévision de la demande.

Si le magasin a accès à un langage de programmation probabiliste (plutôt qu’à une mer de tableurs), il peut estimer bien plus précisément la consommation totale en utilisant l’algèbre des variables aléatoires - généralement absente des langages de programmation classiques.

Programmation différentiable

Dans le contexte de l’optimisation de la supply chain, la programmation différentiable permet à la recette numérique d’apprendre et de s’adapter en fonction des données qui lui sont fournies. La programmation différentiable, une fois combinée avec une descente de gradient stochastique, permet à un supply chain scientist de découvrir des motifs et des relations complexes au sein de la supply chain. Les paramètres sont apprises à chaque nouvelle itération de programmation, et ce processus est répété des milliers de fois. Ceci est fait afin de minimiser l’écart entre le modèle de prévision actuel et les données passées⁴.

La cannibalisation et la substitution - au sein d’un seul catalogue - sont deux problèmes de modèles qui méritent d’être analysés dans ce contexte. Dans les deux scénarios, plusieurs produits se font concurrence pour les mêmes clients, ce qui ajoute une couche complexe de prévision. Les effets en aval de ces forces ne sont généralement pas pris en compte par la prévision traditionnelle des séries temporelles, qui considère principalement la tendance, la saisonnalité, et le bruit pour un seul produit, sans tenir compte de la possibilité d’interaction(s).

La programmation différentiable et la descente de gradient stochastique peuvent être exploitées pour résoudre ces problèmes, par exemple en analysant les données historiques des transactions liant clients et produits. Envision est capable de réaliser une telle investigation - appelée analyse d’affinité - entre clients et achats en lisant de simples fichiers plats contenant une profondeur historique suffisante : en l’occurrence les transactions, les dates, les produits, les clients et les quantités d’achat⁵.

Avec un simple minimum de code unique, Envision peut déterminer l’affinité entre un client et un produit, ce qui permet au supply chain scientist d’optimiser davantage la recette numérique fournissant la recommandation d’intérêt⁶.

Versionnage du code et des données

Un élément souvent négligé de la viabilité de l’optimisation à long terme est de s’assurer que la recette numérique - incluant chaque extrait de code et chaque parcelle de donnée - peut être retrouvée, suivie et reproduite⁷. Sans cette capacité de versionnage, la possibilité de rétroconcevoir la recette est grandement réduite lorsque des exceptions agaçantes surviennent inévitablement (heisenbugs dans les cercles informatiques).

Les heisenbugs sont des exceptions embêtantes qui posent des problèmes dans les calculs d’optimisation, mais disparaissent lorsque le processus est relancé. Cela peut les rendre extraordinairement difficiles à corriger, entraînant l’échec de certaines initiatives et le retour à des tableurs Excel pour la supply chain. Pour éviter les heisenbugs, une réplicabilité complète de la logique et des données de l’optimisation est nécessaire. Cela requiert le versionnage de tout le code et des données utilisés dans le processus, garantissant que l’environnement puisse être reproduit dans les conditions exactes de tout point antérieur dans le temps.

Programmation sécurisée

Au-delà des heisenbugs rebelles, la numérisation accrue de la supply chain entraîne une vulnérabilité conséquente aux menaces numériques, telles que les cyberattaques et les ransomwares. Il existe deux vecteurs principaux - et généralement involontaires - de chaos à cet égard : le(s) système(s) programmable(s) que l’on utilise, et les personnes auxquelles on permet de les utiliser. En ce qui concerne ces dernières, il est très difficile de prévoir l’incompétence accidentelle (sans parler des incidents de malveillance intentionnelle) ; quant aux premières, les choix intentionnels effectués au niveau de la conception sont essentiels pour contourner ces pièges.

Plutôt que d’investir des ressources précieuses dans l’augmentation de l’équipe de cybersécurité (en prévision d’un comportement réactif, tel que la lutte contre les incendies), des décisions prudentes lors de la phase de conception du système de programmation peuvent éliminer des classes entières de maux de tête ultérieurs. En supprimant les fonctionnalités redondantes - comme, dans le cas de Lokad, une base de données SQL - on peut prévenir des catastrophes prévisibles - telles qu’une attaque par injection SQL. De même, opter pour des couches de persistance en mode append-only (comme le fait Lokad) signifie que la suppression de données (par un ami ou un ennemi) est bien plus difficile⁸.

Bien qu’Excel et Python aient leurs avantages, ils ne disposent pas de la sécurité de programmation nécessaire à la protection de l’intégralité du code et des données requis pour le type d’optimisation de la supply chain scalable discuté dans ces conférences.

Notes