Sur la complexité accidentelle des systèmes de supply chain

Joannes Vermorel

Le matériel informatique moderne est extrêmement performant. Un simple smartphone délivre des milliards d’opérations en virgule flottante par seconde (FLOPS) 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 réseau de vente au détail très large. Les données historiques nécessiteraient une représentation appropriée¹ et du côté du traitement des données, des techniques plus légères comme la programmation différentiable devraient être utilisées. Ainsi, des systèmes de supply chain haute performance devraient être une évidence. Bien sûr, les entreprises peuvent se permettre quelque chose de mieux qu’un simple smartphone pour exécuter et optimiser leurs supply chains. Pourtant, une observation occasionnelle des systèmes de supply chain de nos clients chez Lokad indique exactement le contraire : ces systèmes sont presque toujours lents, et souvent tortueux.

Les leaders actuels des logiciels de supply chain (ERP, WMS, MRP, etc.) ont du mal à soutenir même 1 requête par seconde sur leur API backend. Chez Lokad, nous sommes douloureusement rappelés de ces performances horribles quotidiennement, car 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 APIs représente 99,9% du problème. Les systèmes capables de soutenir 1 Mo/seconde pour leur extraction de données sont rares. Les systèmes qui ne nous obligent pas à extraire inutilement les mêmes données encore et encore - pour atteindre les parties les plus récentes - sont encore plus rares. Ces systèmes disposent généralement de plus de 100 ressources informatiques supplémentaires par rapport à ce qu’ils avaient il y a 2 décennies, et pourtant, ils ne sont pas fondamentalement plus rapides³ ni ne font les choses radicalement mieux non plus. Certains des fournisseurs les plus progressistes qui exploitent le calcul en mémoire nécessitent plusieurs téraoctets de RAM pour gérer les réseaux de vente au détail, ce qui représente une quantité de RAM effroyablement élevée⁴ compte tenu de l’utilisation qui est faite de ces ressources.

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

En ce qui concerne les progrès du matériel informatique, il y a encore une décennie, il n’y avait pas une seule (grande) entreprise où la première loi de Moore n’avait pas été présentée des dizaines de fois (généralement de manière incorrecte). Il y avait une 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 incorrecte de progrès indéfini a conduit de nombreuses entreprises de logiciels, bien au-delà du monde de la supply chain, à commettre de graves erreurs. Beaucoup des problèmes associés à Windows Vista (sorti en 2006) pourraient être attribués aux attentes initiales - à l’époque de la sortie de Windows XP en 2001 - des ingénieurs de Microsoft selon lesquelles les processeurs seraient cadencés à 6Ghz d’ici 2006. Nous approchons de la fin de 2020, et les processeurs de jeu haut de gamme atteignent à peine 5Ghz. Le matériel informatique n’a jamais cessé de progresser ; cependant, il a simplement cessé de progresser de manière triviale, du moins en ce qui concerne les entreprises de logiciels.

Dans les années 1980 et 1990, dès qu’un logiciel fonctionnait, même s’il était un peu lent à sa sortie, il était évident que l’année suivante sa vitesse serait correcte, et l’année d’après, sa vitesse serait excellente. Des entreprises de logiciels agressives comme Microsoft ont très bien joué cette carte : leurs ingénieurs disposaient (et disposent toujours) du meilleur matériel informatique que l’argent peut acheter, et ils poussaient systématiquement les performances du logiciel à la limite de ce qui restait acceptable, sachant que le matériel résoudrait essentiellement le problème de performance en une année ou deux. Après le fiasco de Vista, les équipes d’ingénierie de Microsoft ont réalisé l’ampleur du problème et ont changé leur approche - Windows 7 étant une amélioration majeure. Pourtant, il a fallu une décennie à Windows pour véritablement se rétablir sur le plan des performances. De nos jours, la perspective est presque exactement inverse : les meilleures équipes de Microsoft ne misent plus sur le matériel futur, mais se concentrent presque exclusivement sur la fourniture de performances supérieures immédiates grâce à un logiciel supérieur⁵.

Cependant, le monde des logiciels d’entreprise a mis beaucoup plus de temps à remarquer le problème et a continué à développer des logiciels au cours des 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 fois dans le passé. Malheureusement pour la plupart des éditeurs 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 peut simplement attendre que les performances se produisent. Les logiciels ont tendance à accumuler des éléments superflus au fil du 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 - à moins qu’un effort intense et dédié ne soit déployé à cet égard.

Malheureusement, d’un point de vue commercial, les performances sont principalement un non-problème. Les démonstrations sont effectuées avec des comptes fictifs qui ne représentent qu’une infime fraction de la charge de travail des données que le système devrait gérer en production. De plus, les écrans intéressants pour la direction reçoivent une attention disproportionnée par rapport à ceux destinés aux employés de l’entreprise. Pourtant, ce sont précisément ces écrans qui seront utilisés des milliers de fois par jour et qui méritent donc le plus d’attention. Je soupçonne que les API offrent souvent de très mauvaises performances car peu d’acheteurs vérifient si les API fournissent réellement des performances alignées sur leur objectif. Les éditeurs de logiciels le savent et ajustent leurs investissements en ingénierie en conséquence.

Cela m’amène au deuxième aspect du problème de performance : le manque de soin apporté à la conception interne de la solution. À l’heure actuelle, il faut prendre des décisions de conception logicielle stratégiques pour tirer parti de la majeure partie des améliorations matérielles en cours. Pourtant, une décision de conception est à double tranchant : elle donne du pouvoir mais elle limite aussi. Il faut un leadership fort pour s’engager à la fois du côté commercial et du côté technique dans une décision de conception. L’indécision est plus facile, mais à l’inconvénient, comme le montre la grande majorité des logiciels d’entreprise, les performances (et l’expérience utilisateur en général) en souffrent énormément.

Un piège des logiciels modernes (pas seulement ceux d’entreprise) est la surabondance 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 à traiter la “plomberie interne” qui, en soi, n’apporte aucune valeur ajoutée. En termes de conception, la remédiation est à la fois simple à concevoir et difficile à exécuter : il faut faire un usage frugal des composants tiers, en particulier ceux qui impliquent une couche quelconque[^couches]. Du point de vue du fournisseur de logiciels, ajouter une couche de plus est le moyen le plus rapide d’ajouter plus de “fonctionnalités cool” au produit, peu importe le gonflement.

Chez Lokad, nous avons opté pour une pile intégrée de manière extensive en concevant toute notre plateforme autour d’un noyau de compilation. En contrepartie, nous perdons la possibilité de brancher facilement n’importe quel projet open source aléatoire dans notre conception. Les intégrations restent possibles mais nécessitent généralement des modifications plus profondes dans le compilateur lui-même. En revanche, nous obtenons des performances “bare metal” qui sont généralement considérées comme impensables en ce qui concerne les logiciels d’entreprise. Dans l’ensemble, compte tenu du vieillissement 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 a un impact radical sur les performances, du moins d’un point de vue “rapport qualité-prix”. La plupart des logiciels d’entreprise - y compris les logiciels de gestion de la chaîne d’approvisionnement - ont des besoins de ressources informatiques fortement intermittents. Par exemple, à l’extrémité extrême du spectre, nous avons la recette numérique de prévision, qui n’est exécutée qu’une fois par jour (ou environ) mais doit traiter l’ensemble des données historiques à chaque fois. Avoir un ensemble statique de ressources informatiques⁸ dédiées à 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 d’exploitation cloud tout en offrant des performances qui ne seraient pas économiquement viables autrement (les coûts cloud dépasseraient les avantages de la chaîne d’approvisionnement). Afin d’assurer une orchestration globale fluide de toutes les charges de travail, nous avons conçu un degré élevé de “prévisibilité” pour notre propre consommation de ressources informatiques. Le DSL (langage de programmation spécifique au domaine) de Lokad, appelé Envision, a été conçu pour soutenir cette entreprise. C’est pourquoi certaines classes 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é” que suppose le traitement des données de la chaîne d’approvisionnement.

En conclusion, ne vous attendez pas à ce qu’un système de chaîne d’approvisionnement obèse se mette en forme rapidement s’il ne l’est pas déjà. Alors que le matériel informatique continue de progresser, il est déjà suffisamment 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 est insuffisant. Résoudre le problème est possible, mais c’est surtout une question de conception. Malheureusement, la conception logicielle de base est l’une des choses qui tendent à être presque impossibles à corriger dans les logiciels d’entreprise une fois la phase de conception du produit terminée. Il est possible de se rétablir, comme le démontre Microsoft, mais toutes les entreprises (fournisseurs et clients) ne peuvent pas se permettre la décennie nécessaire pour le faire.