Sur la complexité accidentelle des supply chain systems

Joannes Vermorel

Le matériel informatique moderne est extrêmement performant. Un smartphone modeste délivre des milliards de FLOPS (opérations en virgule flottante par seconde) tout en stockant des centaines de gigaoctets de données. Un seul smartphone pourrait techniquement exécuter une allocation prédictive des stocks pour un très grand réseau de distribution. Les données historiques nécessiteraient une représentation adaptée¹ et, pour le traitement des données, des techniques plus légères comme la differentiable programming devraient être utilisées. Ainsi, des systèmes supply chain hautes performances devraient être acquis. Certes, les entreprises peuvent se permettre quelque chose d’un cran mieux qu’un smartphone pour faire fonctionner et optimiser leurs supply chains. Pourtant, une observation fortuite des systèmes supply chain de nos clients chez Lokad indique exactement le contraire : ces systèmes sont presque toujours lents, et souvent tortueusement lents.

Les leaders actuels du logiciel supply chain (ERP, WMS, MRP, etc) ont du mal même à soutenir 1 requête par seconde sur leur backend API. Chez Lokad, nous sommes douloureusement rappelés chaque jour par de si horribles performances, puisque nous sommes en première ligne du processus de récupération des données. Pour une douzaine de clients environ, la récupération initiale des données a pris presque un mois². La lenteur des différentes API représente 99,9 % du problème. Les systèmes capables de soutenir 1 Mo/seconde pour leur extraction de données se font rares. Ceux qui ne nous obligent pas à réextraire inutilement les mêmes données encore et encore – pour atteindre les parties les plus récentes – se font encore plus rares. Ces systèmes disposent typiquement de plus de 100 fois plus de ressources informatiques qu’ils n’en avaient il y a 2 décennies, et pourtant, ils ne sont ni fondamentalement plus rapides³ ni ne font les choses de manière radicalement meilleure. Certains des vendeurs les plus progressistes exploitant le in-memory computing nécessitent plusieurs téraoctets de RAM pour gérer les réseaux de distribution, ce qui représente une quantité affolante⁴ de RAM, compte tenu de ce qui est réalisé avec ces ressources.

Cette complexité accidentelle de nombreux (voire la plupart?) systèmes supply chain peut être attribuée à deux causes profondes : premièrement, des attentes incorrectes concernant le progrès du matériel informatique lui-même, deuxièmement, un manque de soin apporté à la conception interne de la solution.

En ce qui concerne l’évolution du matériel informatique, il y a encore une décennie, il n’existait aucune (grande) entreprise où la première loi de Moore n’avait pas été évoquée des dizaines de fois (généralement de manière incorrecte). On avait l’impression que les ordinateurs devenaient ridiculement plus rapides tout le temps. Malheureusement, cela a cessé d’être trivialement vrai depuis le début des années 2000. Cette perspective erronée d’un progrès indéfini a conduit de nombreuses entreprises de logiciels, bien au-delà du domaine supply chain, à commettre d’énormes erreurs. Beaucoup des problèmes associés à Windows Vista (sorti en 2006) pouvaient être attribués aux attentes initiales – remontant à 2001 lors de la sortie de Windows XP – des ingénieurs de Microsoft, selon lesquelles les CPU seraient cadencés à 6Ghz en 2006. Nous approchons de la fin de 2020, et les CPU haut de gamme pour jeux n’atteignent guère 5Ghz. Le matériel informatique n’a jamais cessé de progresser ; cependant, il a simplement cessé de progresser de manière triviale, du moins du point de vue des entreprises de logiciels.

Dans les années 1980 et 1990, dès qu’un logiciel fonctionnait, même s’il était quelque peu lent à sa sortie, il était entendu que l’année suivante sa vitesse serait correcte, et l’année d’après, elle serait excellente. Des entreprises de logiciels agressives comme Microsoft jouaient très bien cette carte : leurs ingénieurs recevaient (et reçoivent toujours) le meilleur matériel informatique que l’argent puisse acheter, et ils repoussaient systématiquement les performances logicielles jusqu’à la limite de ce qui restait acceptable, sachant que le matériel finirait par résoudre le problème de performance, avec une marge d’une année ou deux. Après la débâcle de Vista, les équipes d’ingénierie de Microsoft ont pris conscience de l’ampleur du problème et ont changé de méthode – Windows 7 représentant une amélioration majeure. Pourtant, il a fallu une décennie à Windows pour véritablement récupérer en termes de performance. De nos jours, la situation est presque exactement l’inverse : les meilleures équipes de Microsoft ne comptent plus sur le matériel futur, et se concentrent presque exclusivement sur la fourniture d’une performance immédiate supérieure via un logiciel supérieur⁵.

Cependant, le monde des logiciels d’entreprise s’est avéré bien plus lent à remarquer le problème, et a continué à développer des logiciels durant les années 2010 comme si le matériel informatique futur était sur le point de résoudre tous leurs problèmes, comme cela s’était produit à de nombreuses reprises par le passé. Malheureusement, pour la plupart des fournisseurs de logiciels d’entreprise, bien que le matériel informatique continue de progresser, il y a une décennie, il a cessé de progresser de manière triviale⁶ où le fournisseur pouvait simplement attendre que la performance se réalise. Les logiciels ont tendance à accumuler des travers avec le temps (plus de fonctionnalités, plus d’options, plus d’écrans, etc.). Ainsi, la tendance naturelle des logiciels complexes est de ralentir avec le temps, et non de s’améliorer – sauf s’il y a un effort intense et dédié sur ce front.

Tristement, du point de vue commercial, la performance est pour la plupart un non-problème. Les démonstrations se font avec des comptes jouets qui ne représentent qu’une infime fraction de la charge de données que le système affrontera en production. De plus, les écrans d’intérêt pour la haute direction bénéficient d’un éclat disproportionné par rapport à ceux destinés aux employés opérationnels. Pourtant, ces derniers sont exactement les écrans qui seront utilisés des milliers de fois par jour et méritent donc le plus d’attention. Je soupçonne que les API offrent fréquemment des performances épouvantables car peu d’acheteurs vérifient si les API fournissent réellement une performance en adéquation avec leur objectif. Les fournisseurs de logiciels le savent, et ils alignent leurs investissements en ingénierie en conséquence.

Ceci m’amène au second aspect du problème de performance : le manque de soin apporté à la conception interne de la solution. Actuellement, il faut des décisions stratégiques de conception logicielle pour tirer parti de la majeure partie des améliorations matérielles en cours. Pourtant, une décision de conception est une arme à double tranchant : elle donne du pouvoir tout en limitant. Il faut un leadership fort, tant du côté commercial que technique, pour s’engager sur une décision de conception. L’indécision est plus facile, mais en contrepartie, comme l’illustre la grande majorité des logiciels d’entreprise, la performance (et l’UX en général) en pâtit grandement.

L’un des écueils des logiciels modernes (et pas seulement ceux d’entreprise) est l’abondance excessive de couches. Les données sont copiées, acheminées, regroupées, synchronisées, … à travers des dizaines de couches internes au sein du logiciel. En conséquence, la majeure partie des ressources informatiques est gaspillée à gérer la « plomberie interne » qui, en soi, n’apporte aucune valeur ajoutée. En termes de conception, la solution est à la fois simple à concevoir et difficile à exécuter : il faut faire un usage parcimonieux des composants tiers, en particulier ceux qui impliquent une sorte de couche⁷. Du point de vue d’un fournisseur de logiciels, ajouter une couche supplémentaire est le moyen le plus rapide d’ajouter des « fonctionnalités sympas » au produit, peu importe l’encombrement.

Chez Lokad, nous avons opté pour une pile étroitement intégrée en concevant l’ensemble de notre plateforme autour d’un noyau compilateur. En contrepartie, nous perdons la possibilité de brancher facilement n’importe quel projet open source dans notre conception. Les intégrations restent possibles mais nécessitent généralement des modifications plus profondes du compilateur lui-même. Par ailleurs, nous atteignons des performances « bare metal » qui sont généralement considérées comme inimaginables en ce qui concerne les logiciels d’entreprise. Dans l’ensemble, compte tenu du vieillissement précaire des composants open source, cette approche s’est révélée particulièrement efficace au cours de la dernière décennie⁸.

La mutualisation multi-locataire est un autre choix de conception qui impacte radicalement la performance, du moins du point de vue du « retour sur investissement ». La plupart des logiciels d’entreprise – le logiciel supply chain en étant un exemplaire – ont des exigences de ressources informatiques très intermittentes. Par exemple, à l’extrême, nous avons la recette numérique de prévision, qui n’est exécutée qu’une fois par jour (ou à peu près) mais doit traiter l’ensemble des données historiques à chaque fois. Disposer d’un ensemble statique de ressources informatiques⁹ dédié à un client est très inefficace.

Encore une fois, chez Lokad, nous avons opté pour une infrastructure entièrement mutualisée. Cette approche réduit nos coûts opérationnels cloud tout en offrant des performances qui ne seraient pas économiquement viables autrement (les coûts du cloud dépasseraient les bénéfices de la supply chain). Afin d’assurer une orchestration globale fluide de toutes les charges de travail, nous avons conçu un haut degré de « prévisibilité » dans notre propre consommation de ressources informatiques. Le DSL de Lokad (langage de programmation spécifique au domaine), nommé Envision, a été conçu pour soutenir cette entreprise. C’est pourquoi des classes entières de constructions de programmation – comme les boucles arbitraires – n’existent pas dans Envision : ces constructions ne sont pas compatibles avec les exigences de « haute prévisibilité » qu’implique le traitement des données de la supply chain.

En conclusion, n’attendez pas qu’un système supply chain obèse se remette en forme de sitôt s’il ne l’est pas déjà. Bien que le matériel informatique continue de progresser, il est déjà assez rapide. Si le système est lent, c’est très probablement parce qu’il antagonise son matériel sous-jacent – et non parce que le matériel manque. Réparer le problème est possible, mais cela relève surtout du design. Malheureusement, la conception fondamentale des logiciels est l’une des choses qui tendent à être presque impossibles à réparer dans les logiciels d’entreprise une fois la phase de conception dépassée. Il est toutefois possible de récupérer, comme l’a démontré Microsoft, mais chaque entreprise (fournisseur et client) ne peut pas se permettre la décennie qu’il faut pour y parvenir.