Sympathie mécanique : L'ingrédient manquant dans le supply chain software

Joannes Vermorel

Lorsque j’ai commencé à travailler sur des problèmes de supply chain il y a près de vingt ans, je m’attendais à ce que la partie difficile soit la physique : camions, navires, palettes, conteneurs, lignes de production. Au lieu de cela, je me suis retrouvé à lutter contre des écrans qui mettaient plusieurs secondes à se rafraîchir, des traitements par lots nocturnes qui débordaient systématiquement jusqu’au lendemain matin, et des moteurs « d’optimisation » qu’il fallait simplifier jusqu’à ce qu’ils soient à peine meilleurs qu’un tableur.

Le véritable goulet d’étranglement n’était pas l’acier ni le béton. C’était le logiciel. Plus précisément, c’était notre indifférence collective envers la machine qui exécute ce logiciel.

Dans mon livre Introduction to Supply Chain, j’affirme que les supply chains modernes sont, avant tout, des moteurs de prise de décision dans l’incertitude. La qualité de ces décisions dépend de la qualité du logiciel qui les prépare, et ce logiciel, à son tour, est limité par le matériel informatique sous-jacent, des caches CPU à la bande passante mémoire.

Au cours de la dernière décennie, j’en suis venu à croire que la pratique du supply chain ne peut progresser davantage à moins que nous ne développions ce que j’appelle la sympathie mécanique : une sensibilité instinctive quant à la manière dont le calcul se comporte réellement, et une volonté de concevoir nos méthodes en fonction de cette réalité plutôt que de l’ignorer.

Ce que j’entends par “Mechanical Sympathy”

Cette expression vient à l’origine du sport automobile. Un bon pilote ne se contente pas simplement de suivre la trajectoire de course ; il “ressent” aussi ce que la voiture peut ou ne peut pas faire. Il évite les manœuvres brutales qui surchauffent les freins, il écoute le moteur, il perçoit quand les pneus sont sur le point de déraper. Il sympathise avec la machine.

En informatique, l’équivalent consiste à comprendre qu’un serveur moderne n’est pas une calculatrice magique et sans friction qui effectue des “opérations par seconde” dans l’abstrait. C’est un objet physique avec ses particularités : de petits caches qui sont rapides mais de taille limitée, une mémoire principale plus lente, des disques encore plus lents, et des réseaux avec une latence que l’on ne peut faire disparaître par un simple souhait. La différence entre respecter ces contraintes et les ignorer systématiquement se traduit par des gains d’un ou deux ordres de grandeur en performance.

Nous avons un exemple frappant dans l’histoire du deep learning. Les premières publications sur les réseaux de neurones étaient obsédées par l’inspiration biologique : neurones, synapses, règles d’apprentissage qui évoquaient les neurosciences. Le tournant est survenu lorsque les chercheurs ont abandonné toute prétention à imiter le cerveau pour optimiser sans pitié en faveur des GPUs et de la stabilité numérique. Les unités linéaires rectifiées, les mini-lots, les couches denses, l’arithmétique en précision mixte : bon nombre de ces idées ne concernent pas tant les neurosciences que l’adaptation au matériel. Le domaine a décollé dès qu’il a montré une sympathie mécanique pour le silicium.

La supply chain n’est bien sûr pas la reconnaissance d’images. Mais elle est tout autant computationnelle, et elle a autant à gagner à respecter la machine.

Supply chain en tant que Problème Computationnel

Les supply chains sont souvent décrites en termes de flux physiques : usines, entrepôts, camions et magasins. Ce qui est moins évident au premier abord, c’est que derrière chaque palette qui se déplace se cachent des dizaines de petites décisions : quoi acheter, quoi produire, combien expédier, où stocker, à quel prix vendre, quand procéder à une baisse de prix, quel ordre prioriser.

Chacune de ces décisions est prise dans l’incertitude. La demande peut augmenter brutalement ou s’effondrer. Les délais de livraison peuvent glisser. Les fournisseurs peuvent échouer. La capacité de transport disparaît du jour au lendemain. Si nous voulons rendre ces décisions systématiquement meilleures que de simples approximations humaines, nous avons besoin d’algorithmes qui considèrent de nombreux scénarios, et pas seulement une unique prévision ; qui comparent les options en termes de profit attendu, et pas seulement de taux de service ; qui propagent les contraintes à travers l’ensemble du réseau au lieu de traiter chaque entrepôt ou magasin de manière isolée.

Tout cela est coûteux en termes de calcul. Une approche probabiliste qui suit des milliers d’avenirs plausibles et évalue les décisions pour chacun d’eux effectuera bien plus d’opérations arithmétiques qu’une formule simpliste de sécurité de stocks. Une vision au niveau du réseau qui associe les stocks, la tarification et la planification de capacité fera passer bien plus de données par la machine qu’un simple calcul de point de commande local.

C’est ici que la sympathie mécanique devient décisive. Si la pile logicielle et matérielle sous-jacente est bâclée, si chaque requête déclenche des dizaines d’allers-retours vers une base de données transactionnelle, si les algorithmes sont écrits de manière à contrecarrer la mise en cache et le parallélisme, alors ces méthodes plus sophistiquées ne s’insèrent tout simplement pas dans la fenêtre temporelle disponible. Vous finissez par réduire le problème jusqu’à ce qu’il tienne dans la machine, au lieu d’améliorer la machine pour qu’elle puisse traiter le véritable problème.

Quand je vois une entreprise dont « l’optimisation » du réapprovisionnement doit démarrer à 18 h pour se terminer à 6 h, je sais que l’organisation n’expérimentera jamais sérieusement d’alternatives. Chaque nouvelle idée devient un projet de plusieurs semaines, car il faut une demi-journée juste pour obtenir un seul lancement. L’économie de l’expérimentation s’effondre.

La Vision Dominante : Le Matériel Relégué au Second Plan

Si vous consultez les manuels de supply chain grand public, vous trouverez de longues discussions sur la conception de réseaux, les stratégies de sourcing, les contrats, les politiques de stocks, les modes de transport et les indicateurs de performance. Vous trouverez également des chapitres sur la technologie de l’information décrivant les systèmes ERP, les outils de planification et l’intégration. Ce que vous trouverez presque jamais, c’est une discussion sérieuse sur le fonctionnement effectif de l’informatique sous-jacente.

La technologie de l’information est considérée comme un facilitateur neutre. Le message, en gros, est qu’une fois que vous avez choisi votre logiciel et intégré vos données, vous pouvez vous concentrer sur la conception des processus et les leviers managériaux. La vie interne de la machine – comment la mémoire est organisée, comment les données sont stockées, comment le calcul est planifié – relève des fournisseurs et des techniciens.

Le même état d’esprit imprègne la plupart des logiciels d’entreprise dans notre domaine. Les systèmes de planification sont construits sur des bases de données transactionnelles qui ont été conçues à l’origine pour réserver des commandes et mettre à jour les niveaux de stocks, et non pour traiter des milliards de scénarios probabilistes en une nuit. L’architecture est généralement organisée autour d’écrans et de formulaires qui créent, lisent, mettent à jour et suppriment des enregistrements. Des « modules d’optimisation » supplémentaires sont ajoutés : un moteur de prévision ici, un solveur de routage là, une heuristique de stocks quelque part ailleurs.

De l’extérieur, cela semble suffisamment moderne : interfaces web, déploiement cloud computing, API, peut-être même de l’“AI” dans la brochure marketing. Sous le capot, cependant, le noyau computationnel est souvent à court de ressources. Les calculs sont distribués à travers des couches d’abstraction qui fragmentent les données, dispersent le travail et neutralisent les atouts du matériel. Le résultat est un logiciel qui a du mal à suivre les volumes de données d’aujourd’hui malgré son exécution sur des machines des milliers de fois plus rapides que celles d’il y a trente ans.

Niklaus Wirth a célèbrement plaisanté que les logiciels deviennent plus lents plus rapidement que le matériel ne s’accélère. En supply chain, on peut le constater directement : il faut encore plusieurs secondes pour ouvrir la page de “détails” pour une seule combinaison produit-localisation dans de nombreux grands systèmes, alors que le matériel sous-jacent devrait être capable de scanner des millions d’enregistrements similaires dans le même laps de temps. Nous avons réussi à épuiser presque tout le progrès du matériel dans des couches d’inefficacité.

Une fois que l’inefficacité est intégrée à l’architecture, les conséquences ne sont pas seulement techniques ; elles deviennent doctrinales. Si votre plateforme ne peut pas se permettre de suivre des milliers de scénarios pour chaque SKU, alors vous favoriserez des méthodologies qui ne requièrent qu’une seule prévision. Si votre moteur ne peut pas évaluer l’impact financier des décisions au niveau du réseau, vous vous orienterez vers des règles locales et des indicateurs clés de performance qui peuvent être calculés de manière isolée. Les limitations “théoriques” se transforment rapidement en dogmes “pratiques”.

Ce qui change lorsque vous prenez en compte la machine

Que se passe-t-il si nous renversons le scénario ? Supposons que nous partions du postulat que la machine compte.

Premièrement, nous commençons à concevoir des flux de données qui respectent la localité. Au lieu de disperser l’information dans des dizaines de tables et de demander à la base de données de les recoller lors de chaque calcul, nous organisons les données de sorte qu’un seul passage en mémoire fournisse tout ce dont un algorithme a besoin. Cela à lui seul peut améliorer la performance d’un ordre de grandeur complet.

Deuxièmement, nous privilégions les opérations par lots et vectorisées plutôt que le traitement bavard, ligne par ligne. Le matériel est extraordinairement performant pour effectuer la même opération encore et encore sur de grands tableaux. Il est terrible pour répondre à des milliers de petites questions sans lien, qui nécessitent de sauter d’un endroit à l’autre en mémoire et à travers le réseau. Lorsque la partie analytique d’un système de supply chain est exprimée comme un programme cohérent plutôt que comme une multitude de transactions guidées par des formulaires, il devient beaucoup plus facile de tirer parti de cette force.

Troisièmement, nous considérons l’ensemble du processus décisionnel, des données brutes aux quantités qui figurent sur les bons de commande et les listes de prélèvement, comme quelque chose qui peut et doit être profilé, optimisé et réingénieré au fil du temps. Nous arrêtons de traiter “le modèle” comme une boîte noire et commençons à considérer la recette comme un logiciel. C’est précisément ce qui a permis à des domaines tels que l’infographie et le calcul scientifique d’évoluer de prototypes lents en outils industriels : des ingénieurs ont passé des années à éliminer les inefficacités à chaque niveau.

Le bénéfice direct est la rapidité. Un calcul qui prenait six heures auparavant pourrait désormais prendre six minutes, voire six secondes. Mais le bénéfice plus profond n’est pas ce chiffre brut ; c’est ce que cette rapidité rend possible. Si votre équipe peut exécuter une centaine de variantes d’une politique de réapprovisionnement en une journée au lieu d’une seule variante par semaine, elle explorera des idées qui étaient auparavant impensables. Elle affinera les modèles en réponse aux perturbations, testera des hypothèses alternatives et repoussera progressivement les limites de ce qui est économiquement réalisable.

Ce n’est pas de la vanité geek, c’est l’économie

Certains lecteurs pourraient s’inquiéter du fait que tout cela ressemble à l’obsession d’un ingénieur pour l’élégance en soi. Qui se soucie du nombre de cache misses d’un algorithme, tant que les étagères sont bien approvisionnées et que les camions partent à l’heure ?

La réponse est que l’inefficacité n’est pas gratuite. À l’ère du cloud computing, vous en payez le prix doublement.

Vous payez directement, sous la forme d’une infrastructure surdimensionnée. Si votre logiciel nécessite dix fois plus de capacités de calcul et de stockage que nécessaire pour produire les mêmes décisions, vous paierez dix fois plus à votre fournisseur cloud ou pour votre matériel – ou vous accepterez des temps d’exécution dix fois plus longs, ce qui représente simplement une autre forme de coût.

Vous payez également de manière indirecte, sous la forme d’une logique décisionnelle affaiblie. Parce que les systèmes inefficaces peinent à calculer des politiques sophistiquées à grande échelle, les fournisseurs simplifient les mathématiques pour s’adapter à la machine. Ils réduisent les distributions de probabilités à des nombres uniques. Ils découplent des processus qui sont étroitement liés dans la réalité afin qu’ils puissent être calculés en passes séparées. Ils dissimulent des approximations grossières derrière des tableaux de bord attrayants. Vous ne verrez peut-être jamais ces raccourcis, mais vous les ressentirez sous forme de stocks de sécurité excessifs, de ventes manquées et de réactions fragiles face aux chocs.

La sympathie mécanique, en revanche, vous permet d’investir votre budget de calcul là où cela compte le plus : dans l’exploration de l’incertitude et des compromis. Un système efficace peut se permettre de simuler des milliers d’avenirs et de choisir des décisions qui maximisent le profit attendu tout en contrôlant le risque, plutôt que de s’appuyer sur des règles empiriques. Il peut se permettre de recalculer fréquemment, afin que les décisions restent actualisées face aux nouvelles données. Il peut se permettre de garder l’ensemble du réseau en vue au lieu d’optimiser myopiquement chaque nœud de manière isolée.

En ce sens, la sympathie mécanique n’est pas une préférence technique ; c’est une posture économique. Elle affirme : nous ne gaspillerons pas des ressources de calcul rares en frais superflus ; nous les investirons dans les calculs qui changent réellement nos flux de trésorerie.

Ce que j’attends des dirigeants du supply chain

Tout cela ne signifie pas que chaque dirigeant du supply chain doit devenir programmeur de systèmes. Mais je crois en effet que les équipes dirigeantes ont besoin d’un sens de la grandeur et d’une direction de base. Il n’est pas nécessaire de concevoir des moteurs pour savoir qu’un camion qui consomme trois fois plus de carburant que ses pairs pour le même trajet est un problème. Il n’est pas nécessaire d’être concepteur de puces pour reconnaître qu’un système qui prend des heures pour effectuer un calcul qui pourrait raisonnablement être fait en quelques secondes pose problème.

Lorsque vous sélectionnez un logiciel ou un fournisseur, vous devriez vous sentir à l’aise pour poser des questions telles que :

À quelle fréquence pouvons-nous recalculer de manière réaliste toutes les décisions clés pour l’ensemble du réseau ?

Que se passe-t-il si nous doublons le nombre de SKU ou de localisations – les temps d’exécution doublent-ils, ou explosent-ils ?

De quel matériel cette plateforme a-t-elle besoin pour traiter nos données, et dans quelle mesure sommes-nous convaincus que ces exigences ne vont pas exploser d’ici deux ans ?

Si les réponses sont évasives, ou si personne dans la salle ne peut même estimer les ordres de grandeur, quelque chose cloche. Dans la conversation LokadTV sur les ressources de calcul, j’ai comparé cela à une géographie de base : vous n’avez pas besoin de connaître l’altitude exacte de chaque montagne, mais vous devriez savoir si une route donnée traverse les Alpes ou une plaine.

De même, les équipes internes devraient être encouragées à considérer leur travail analytique comme du code qui peut être profilé et amélioré, et non comme des “modèles” statiques qui sont soit corrects, soit erronés. La capacité à raisonner sur la performance fait partie de la compétence professionnelle, tout comme la capacité à raisonner sur l’économie unitaire fait partie de la finance.

Un autre type de sympathie

La sympathie mécanique est en fin de compte une forme de respect.

C’est du respect pour la machine : reconnaître que nos serveurs ne sont pas infinis, que leurs bizarreries et limites sont réelles, et que les ignorer nous expose à des risques.

C’est du respect pour les personnes qui dépendent de ces machines : des planificateurs qui ont besoin de recommandations opportunes et fiables ; des managers qui nécessitent une marge de manœuvre pour expérimenter ; des dirigeants qui doivent engager des capitaux en se basant sur ce que le logiciel leur indique.

Et c’est du respect pour la discipline du supply chain elle-même. Si nous affirmons que notre domaine consiste à prendre de meilleures décisions dans l’incertitude, alors nous ne pouvons ignorer la qualité des machines qui produisent ces décisions. Nous nous devons, à nous-mêmes – et aux entreprises qui nous font confiance – de traiter les ressources de calcul aussi sérieusement que nous traitons les entrepôts et les flottes.

La vision dominante a toujours consisté à traiter les aspects internes du matériel et des logiciels comme une préoccupation de coulisses, quelque chose que « IT s’en occupera ». Je crois que cette vision a atteint la fin de son utilité. Plus nos supply chains dépendent d’algorithmes et de données, plus nous devons mettre la machine sous les projecteurs.

La sympathie mécanique ne signifie pas transformer chaque planificateur en programmeur. Cela signifie cultiver, à chaque niveau, une curiosité éclairée sur le fonctionnement réel de nos outils – et refuser d’accepter la lenteur, l’opacité et le gaspillage comme quelque chose d’inévitable.