Oui. Dans une certaine mesure. Et je n’aurais jamais osé avancer cette opinion lorsque j’ai fondé Lokad il y a près d’une décennie.

Par compilation, je fais référence à l’art de concevoir des compilateurs, c’est-à-dire des programmes informatiques qui traduisent du code source dans un autre langage. Peu de personnes en dehors du cercle des programmeurs savent ce qu’est un compilateur et peu de personnes parmi les programmeurs savent comment concevoir un compilateur. Au premier abord, les préoccupations liées à la compilation semblent éloignées (pour le moins que l’on puisse dire) des préoccupations de la supply chain. Pourtant, de nos jours, chez Lokad, ce sont les choses liées à la compilation qui sauvent la situation ; projet supply chain après projet supply chain.

Auto-promotion éhontée : les ingénieurs logiciels ayant des compétences en compilation ne poussent pas sur les arbres, et nous recrutons. Vous voulez travailler sur des choses qui comptent ? Eh bien, la prochaine fois que votre avion sera en retard parce qu’une pièce manquait, ou la prochaine fois que le médicament que vous recherchez sera en rupture de stock, souvenez-vous que vous auriez pu faire la différence en rejoignant Lokad :-)

Les supply chains sont complexes, incroyablement complexes. La mondialisation a multiplié les opportunités d’approvisionnement, mais les retards sont plus longs et plus erratiques que jamais. Les canaux de vente se multiplient également : il y a des magasins physiques, des magasins en ligne, des places de marché, des revendeurs, des grossistes, … Et maintenant, grâce à Amazon, tout le monde, partout, s’attend à ce que tout soit commandé et reçu du jour au lendemain. Les attentes en matière de supply chain sont plus élevées que jamais.

Aborder les problèmes de supply chain avec autre chose que l’expressivité complète d’un langage de programmation ne fonctionne pas. Tout comme la programmation Lego ne se produira pas, les défis de la supply chain ne s’inscriront pas dans des cases à cocher et des menus déroulants. Cela n’empêche pas les éditeurs de logiciels d’essayer, notez bien. Les solutions qui comprennent plus de 1000 tables, chaque table comportant en moyenne environ 100 champs, sont trop courantes. Et même si l’entreprise cliente n’utilise qu’environ 1% de la zone de fonctionnalités de la solution, elle doit quand même faire face à sa complexité envahissante.

La compilation sauve la situation car elle fournit un ensemble considérable de connaissances et de savoir-faire en ce qui concerne la création d’abstractions de haute qualité destinées à résoudre des problèmes statistiques et combinatoires (et bien plus encore en réalité). Et la plupart des défis de la supply chain se révèlent être précisément statistiques et combinatoires. Par exemple, chez Lokad, en introduisant une algèbre des distributions, nous avons réussi à “résoudre” des problèmes complexes de délais d’approvisionnement qui résistaient à nos approches plus directes par le biais de fonctionnalités logicielles packagées.

Ce qui distingue les fonctionnalités linguistiques des fonctionnalités habituelles des applications (wysiwyg), c’est que les fonctionnalités linguistiques sont beaucoup moins sensibles aux spécificités d’un défi donné que leurs homologues des fonctionnalités des applications. Par exemple, considérons une situation où votre logique de détection des ruptures de stock échoue dans le cas spécifique de produits ultra-saisonniers. Si la fonctionnalité est livrée par le biais d’une construction linguistique, vous pouvez toujours restreindre la portée des données jusqu’à ce que la fonctionnalité fonctionne exactement là où elle est censée le faire ; en ajustant éventuellement dynamiquement la portée grâce à une analyse numérique ad hoc. En revanche, avec une fonctionnalité d’application, vous êtes coincé avec les options de filtrage qui ont été intégrées à cette fonctionnalité. Les fonctionnalités d’application conviennent uniquement si vos problèmes sont étroits et bien définis, ce qui est en réalité très différent de l’optimisation de la supply chain.

En supply chain, la programmabilité brille car :

  • Les problèmes sont à la fois très numériques et très structurés
  • Les supply chains sont modulaires et cette modularité doit être exploitée
  • Le nombre de variables est important mais pas écrasant
  • Adapter précisément la forme des problèmes est essentiel

Il est légèrement amusant de constater combien de fournisseurs de logiciels ont tendance à réinventer progressivement la programmabilité. À mesure que l’interface utilisateur devient plus profonde et complexe, avec la possibilité d’ajouter des filtres, des options, des hooks de pré-traitement ou de post-traitement, des alertes modélisées, des moniteurs de KPI, l’interface utilisateur devient progressivement une chose programmable, et atteint le point où seul un programmeur peut réellement lui donner un sens (grâce précisément à ses compétences de programmation préexistantes). Programmable oui, mais de manière très complexe.

La compilation est l’art d’amplifier les compétences en ingénierie : il faut créer des abstractions et des constructions de langage qui rationalisent la résolution des problèmes. Comme l’a écrit Brian Kernighan : Tout le monde sait que le débogage est deux fois plus difficile que l’écriture d’un programme en premier lieu. Alors, si vous êtes aussi intelligent que possible lorsque vous l’écrivez, comment allez-vous le déboguer ? La même logique s’applique à l’optimisation de la supply chain, car c’est essentiellement la même chose que l’écriture de code. Eh bien, chez Lokad, c’est littéralement la même chose.

La sagesse conventionnelle de l’informatique dit qu’il faut automatiser d’abord les parties faciles, laissant aux experts humains le soin de gérer les éléments plus complexes. Pourtant, en supply chain, cette approche échoue lamentablement à chaque fois. Les parties les plus complexes de la supply chain sont presque toujours les plus coûteuses, celles qui nécessitent une attention urgente. Les parties faciles peuvent se gérer elles-mêmes grâce à un inventaire min/max ou à la méthode Kanban. Tout comme vous ne construiriez pas de logiciel pour les voitures autonomes en affinant un logiciel pour les opérations de train automatiques, vous ne pouvez pas résoudre les problèmes difficiles de la supply chain en affinant un logiciel initialement conçu pour résoudre des défis simples.

Naturellement, la compilation seule ne suffit pas à faire face aux défis de la supply chain. Le machine learning, le traitement des big data et une quantité considérable de compétences humaines méritent également d’être mentionnés. Cependant, dans tous les cas, avoir des abstractions de haute qualité soigneusement élaborées aide considérablement. Le machine learning est beaucoup plus simple lorsque les données d’entrée sont bien préparées. Le traitement des big data est également beaucoup plus simple lorsque les calculs se prêtent facilement à un degré élevé de parallélisation.