Pourquoi pas Python

Joannes Vermorel

Il y a des années, mais aussi des années après la fondation de Lokad, j’ai réalisé qu’aucune application unique ne pourrait jamais atteindre la grandeur en ce qui concerne l’optimisation de la supply chain. Nous avons fait de notre mieux, mais cela n’était pas suffisant. Peu importe le nombre de fonctionnalités que nous ajoutions aux premières versions de Lokad, chaque nouveau client semblait désespérément différent de tous ceux que nous avions réussi à couvrir jusqu’à présent. Les défis de la supply chain sont tout simplement trop divers et trop chaotiques pour être encadrés dans un nombre raisonnable de menus, de boutons et d’options.

En fait, la majorité de nos concurrents reconnaissent cette situation et ont opté pour la construction de produits logiciels comportant un nombre insensé de menus, de boutons et d’options, tout cela dans une tentative désespérée de faire face à tous les défis de la supply chain. Malheureusement, cette voie conduit à des monstres logiciels qui se transforment en échecs spectaculaires lorsqu’ils sont déployés à grande échelle. Je fais référence à cet antipattern comme à l’Horreur Non-Euclidienne.

Ainsi, face à une classe de problèmes - c’est-à-dire les défis de la supply chain - qui ne pouvaient tout simplement pas être résolus avec une seule application, nous avons commencé, en partie accidentellement¹, à aborder le méta-problème : comment fournir des applications sur mesure où chaque application serait dédiée à la résolution d’un seul problème pour une situation donnée, par exemple l’optimisation du réapprovisionnement pour une entreprise spécifique.

Fournir des logiciels sur mesure pour les entreprises n’est pas nouveau. L’industrie du logiciel a commencé de cette manière dans les années 60, et a ensuite évolué dans les années 80 vers le modèle dominant shrinkwrap que nous connaissons aujourd’hui. En règle générale, les logiciels sur mesure ont tendance à avoir de nombreuses propriétés indésirables par rapport aux logiciels shrinkwrap : des investissements initiaux plus élevés, des configurations longues, des coûts de maintenance plus élevés, des risques plus élevés, etc.

Pourtant, l’expérience que j’avais acquise au cours des premières années de Lokad indiquait que, en ce qui concerne l’optimisation de la supply chain, les logiciels sur mesure avaient un avantage clé : ils fournissaient en réalité des résultats exceptionnels. En effet, tandis que notre application d’origine ne fournissait au mieux que des résultats acceptables², quel que soit le degré de précision des prévisions, ces prototypes faisaient fréquemment des merveilles. De plus, le seul tour de passe-passe consistait en la spécialisation extrême de la partie logicielle destinée au problème en question.

Après avoir épuisé ce qui semblait être toutes les alternatives, nous avons conclu que la fourniture d’applications sur mesure était la seule voie à suivre. Cependant, la scalabilité ; comment fournir de nombreuses applications, et la maintenabilité ; comment maîtriser les coûts de maintenance, étaient deux préoccupations majeures. Tout d’abord, nous devions choisir un langage de programmation. À l’époque, nous avons envisagé de nombreuses options : R, Python, JavaScript, Lua, C#, … et de développer notre propre langage de programmation spécifique au domaine (DSL), qui serait plus tard connu sous le nom d’Envision. Discuter des avantages et des inconvénients de toutes ces options serait quelque peu fastidieux³, donc dans un souci de clarté, la discussion devait se limiter au choix entre Python et Envision ; Python étant le concurrent le plus sérieux face au développement de notre propre DSL.

Python était attrayant en raison de sa simplicité et de son riche écosystème de bibliothèques tierces, notamment dans le domaine de l’apprentissage automatique⁴. C’était également une option à faible coût pour Lokad : comme Python, et pratiquement toutes ses bibliothèques populaires, sont open source, nous aurions simplement repackagé un sous-ensemble restreint de Python, en autorisant quelques dizaines de packages soigneusement sélectionnés, et nous en aurions fini avec ça. La plupart du travail pour Lokad aurait été axé sur la fourniture d’une expérience PaaS autour de Python, aussi adaptée que possible aux défis de la supply chain.

Cependant, voici un test décisif que nous avons envisagé : était-il raisonnable de s’attendre à ce qu’un analyste d’affaires - plus tard connu sous le nom de Supply Chain Scientist - travaillant 1 jour par semaine pendant 6 mois fournisse une application de qualité de production pour résoudre un défi critique pour la supply chain, comme le réapprovisionnement, pour une entreprise de 10 millions de dollars ? En examinant l’option Python, il était clair que nous ne pourrions jamais approcher un tel niveau d’efficacité opérationnelle.

Premièrement, Python nécessite des ingénieurs en logiciel. En effet, Python, comme tout langage de programmation complet, expose de nombreuses subtilités techniques à quiconque écrit du code en Python. Bien que le rôle du supply chain scientist n’ait été formalisé que plus tard, nous avions dès le départ l’intuition que même en considérant des personnes talentueuses et intelligentes, s’attendre à ce qu’elles soient à la fois des experts en ingénierie de la supply chain et des experts en ingénierie logicielle était trop demander. Nous avions besoin de capacités de programmation accessibles à un large éventail de personnes techniquement compétentes, pas seulement à des ingénieurs logiciels professionnels.

Ainsi, nous avons conçu Envision comme un langage permettant d’éliminer des classes entières de problèmes techniques inévitables avec Python. Par exemple :

• Les objets peuvent être null, les dates peuvent être absurdes, dans le passé ou dans le futur, NaN peut se propager joyeusement dans votre pipeline de données, les chaînes de caractères peuvent devenir énormes… Dans la supply chain, ces “fonctionnalités” ne sont rien d’autre que des problèmes en attente de se produire.
• Les éléments orientés objet (c’est-à-dire les classes) sont garantis d’être mal utilisés⁵, et on peut en dire autant des exceptions personnalisées ou des expressions régulières. La simple présence de ces éléments est, au mieux, une distraction malsaine.
• De nombreuses opérations de base telles que l’analyse de fichiers tabulaires disparates (y compris les feuilles de calcul Excel) ne font pas partie du langage et nécessitent de traiter de nombreux packages disparates, chacun ayant ses propres subtilités techniques.

Aucune de ces classes de problèmes techniques ne peut être supprimée de Python sans handicaper le langage lui-même. Envision, en tant que langage de programmation, est accessible aux spécialistes de la supply chain (par opposition aux spécialistes du logiciel) uniquement en raison de son attention extrême portée sur les problèmes d’optimisation prédictive de la supply chain.

Pensez à la dernière fois où vous avez dû effectuer des calculs avec une feuille de calcul Excel, et imaginez-vous dicter tous les changements que vous avez apportés à cette feuille Excel par téléphone sans pouvoir voir la feuille Excel vous-même. C’est à cela que ressemble une initiative d’optimisation de la supply chain pilotée par des praticiens, mais mise en œuvre par des ingénieurs logiciels (non spécialistes de la supply chain). Les entreprises passent énormément de temps à transmettre ce qu’elles veulent à l’informatique ; et l’informatique passe énormément de temps à essayer de comprendre ce que l’entreprise veut. Après une décennie d’expérience chez Lokad, j’observe que s’appuyer sur des développeurs logiciels, qui ne sont pas des spécialistes de la supply chain, pour mettre en œuvre une initiative d’optimisation de la supply chain quantitative multiplie les coûts par au moins un facteur 5, quelle que soit l’agilité et le talent de l’équipe logicielle.

Deuxièmement, les coûts de maintenance des prototypes Python hâtifs explosent. En dehors de l’industrie du logiciel, peu de gens réalisent que l’ingénierie logicielle⁶ consiste principalement à maîtriser les coûts de maintenance. Pourtant, résoudre les problèmes d’optimisation de la supply chain est un processus chaotique : les données provenant de nombreux systèmes (peu fiables) doivent être acheminées de manière fiable, les processus imparfaits et en constante évolution doivent être documentés et modélisés, les métriques d’optimisation reflètent une stratégie commerciale en constante évolution, etc. En conséquence, quel que soit le logiciel écrit pour fournir l’optimisation de la supply chain, il intègre toujours une dose massive de complexité spécifique au domaine, simplement pour faire face à ce que le monde nous lance.

Pourtant, le temps est essentiel. Il est inutile d’avoir le plan parfait pour le plan de production de l’année dernière. En règle générale, on peut supposer que le jour où le prototype logiciel commence à fonctionner, il sera mis en production en quelques semaines, que le prototype soit bien ou mal écrit.

S’attendre à ce que la direction approuve un délai de 6 mois pour réécrire le prototype afin de le rendre adapté à la production du point de vue de la maintenance relève de l’utopie. Pourtant, mettre un prototype Python hâtif en production est la recette pour des coûts de maintenance épiques, se battre contre une avalanche incessante de bugs qui devront être colmatés 24 heures sur 24, 7 jours sur 7.

Ainsi, la seule façon pratique de maintenir la production saine est d’écrire le prototype avec un langage de programmation qui garantit un haut degré de correction par conception. Par exemple, contrairement à Python, Envision offre :

• Un temps d’exécution fini garanti au moment de la compilation : lors du traitement de plusieurs téraoctets de données, il devient très fastidieux d’attendre des heures avant de réaliser qu’un calcul ne se terminera tout simplement jamais. Une consommation de mémoire bornée garantie au moment de la compilation : lutter contre les erreurs de mémoire insuffisante dans le lot de production nocturne n’est pas du tout amusant et, en pratique, perturbe considérablement les opérations.
• Des lectures et écritures atomiques : Envision empêche, par conception, les lectures et écritures concurrentes dans le système de fichiers, même lorsque des fichiers sont transférés via FTP pendant l’exécution de scripts. Le système de fichiers sous-jacent à Envision est pratiquement un Git adapté aux fichiers plats gigantesques. Sans une versionnage de données approprié, de nombreux bugs se transforment en heisenbugs : au moment où quelqu’un se penche sur le problème, les données ont été actualisées et le problème ne peut plus être reproduit.
• Une exécution évolutif du programme sur un cloud de ressources informatiques, éliminant tous les obstacles de parallélisation qui sont inévitables dès que les données dépassent quelques dizaines de gigaoctets.

Les langages de programmation génériques offrent peu de correction par conception ; et Python, penché vers le spectre du late binding, offre extrêmement peu dans ce domaine. Même en considérant de meilleures alternatives - du point de vue de la correction par conception - comme Rust, ces alternatives ne sont nullement satisfaisantes pour l’optimisation de la supply chain.

Voici quelques autres domaines où Envision brille de manière tout simplement inaccessible à Python :

Défense en profondeur : Dès que quelqu’un commence à écrire du code dans votre organisation, à moins de prendre des précautions très particulières⁷, leur code devient immédiatement une responsabilité du point de vue de la sécurité informatique. Avec Python, il est pratiquement possible de faire n’importe quoi sur la machine exécutant le script Python. Mettre en place un sandboxing approprié pour Python est un problème diaboliquement compliqué. En particulier, toute chaîne de caractères produite par le script Python est un vecteur potentiel d’injection. Alors que les injections SQL sont notoires, (trop) peu de personnes réalisent que même des fichiers texte plats comme les CSV sont vulnérables aux attaques par injection. Envision offre un degré de sécurité qui ne peut tout simplement pas être reproduit avec Python. Les violations de données sont en hausse, éparpiller des morceaux de Python partout ne fera aucun bien à la sécurité informatique.

Performance transparente : Si un programme est trop lent pour être exécuté, alors ce programme ne devrait même pas être compilé en premier lieu⁸. Si un programme est raccourci d’une ligne, alors le programme devrait s’exécuter plus rapidement. Si une seule ligne est modifiée, seule cette ligne devrait être recalculée⁹ lors de la réexécution du programme sur les mêmes données. Lors de la compilation, le compilateur ne devrait pas cibler une machine donnée mais un cloud de ressources informatiques, offrant une parallélisation automatique basée sur les données. Envision fait beaucoup de chemin pour offrir toutes ces propriétés par défaut, sans aucun effort de codage. En revanche, cela nécessite une utilisation massive de bibliothèques spécialisées en Python pour commencer à approximer de telles propriétés.

Mise à niveau transparente : L’état de l’art est une cible en mouvement constant en ce qui concerne les logiciels. En 2010, la meilleure boîte à outils d’apprentissage automatique était SciPy (arguablement). En 2013, c’était scikit. En 2016, c’était Tensorflow. En 2017, c’était Keras. En 2019, c’était PyTorch. Il existe un dicton dans l’ingénierie logicielle selon lequel vous pouvez dater l’année de naissance de n’importe quel projet logiciel en regardant sa pile logicielle et ses dépendances. En effet, dès que vous déployez vos propres scripts Python, vous intégrez plusieurs dépendances qui peuvent ne pas bien vieillir. En revanche, avec Envision, nous utilisons largement des réécritures de code automatisées¹⁰ pour maintenir les scripts “hérités” à jour avec un langage en constante évolution.

Stack packagé : Les scripts Python ne peuvent pas vivre en vase clos¹¹. Le code doit être versionné (par exemple, Git) avec des droits d’accès (par exemple, GitHub). Ils ont besoin d’un environnement d’exécution qui n’est pas votre machine (par exemple, une machine virtuelle Linux dans le cloud). Un planificateur est nécessaire pour orchestrer le pipeline de données (par exemple, AirFlow). Une couche de stockage colonne distribuée est nécessaire pour la préparation des données (par exemple, Spark). Une boîte à outils d’apprentissage automatique est nécessaire pour l’analyse prédictive (par exemple, TensorFlow). Une boîte à outils d’optimisation est nécessaire pour traiter les problèmes combinatoires de la chaîne d’approvisionnement (par exemple, GLPK). Les résultats bruts doivent être exposés quelque part pour une consommation ultérieure (par exemple, un serveur SFTP). Les praticiens de la chaîne d’approvisionnement doivent pouvoir surveiller ce qui se passe (par exemple, une interface utilisateur web). Les droits d’accès doivent être appliqués (par exemple, Active Directory), etc. Envision simplifie tout cela dans une seule méta-application, éliminant la charge d’assembler des dizaines de logiciels pour fournir même l’application la plus basique.

Ensuite, bien que ce soit un excellent langage, Python n’est pas exempt de reproches :

• Les performances de calcul sont mauvaises, et c’est une bataille difficile de faire passer chaque calcul par la bonne bibliothèque (par exemple, NumPy) pour éviter d’obtenir des performances désastreusement mauvaises lors des tâches de traitement des données. De plus, l’utilisation de plusieurs bibliothèques crée souvent beaucoup de friction lorsque les données doivent être déplacées d’une bibliothèque à l’autre.
• Les performances de la mémoire sont également mauvaises, et en particulier, la collecte des déchets par comptage de références de Python est obsolète - et tous les langages de programmation plus récents comme Java, C# ou JavaScript utilisent plutôt le traçage. Lorsqu’il s’agit de tâches intensives en mémoire avec de grandes quantités de données, cela pose problème.
• La gestion des packages en Python a été un désordre pendant longtemps, et il faut un spécialiste des packages pour bien faire les choses. De plus, ce problème a été aggravé par les mises à jour de langage à friction élevée.
• La plupart des (rares) vérifications de correction ne se produisent qu’à l’exécution, lorsque le programme est exécuté, ce qui est une source de frustration sans fin lorsqu’il s’agit de traitement de données. Les problèmes évidents ne se manifestent qu’après plusieurs minutes d’exécution, ce qui réduit la productivité.

En conclusion, bien que Python soit génial (et il l’est), ce n’est pas une réponse satisfaisante pour l’optimisation de la supply chain. Construire et maintenir une application d’apprentissage automatique de qualité de production en Python est tout à fait possible, mais les coûts sont importants, et à moins que votre entreprise ne soit prête à avoir au moins une petite équipe d’ingénierie logicielle dédiée à la maintenance de cette application, le tout ne donnera pas de résultats satisfaisants pour votre supply chain.

Le développement d’Envision, un langage de programmation spécifique au domaine dédié à l’optimisation prédictive de la supply chain, n’était pas notre premier choix. Ce n’était même pas notre 10e choix. C’était plutôt la seule solution fonctionnelle que nous avions après avoir épuisé une longue liste d’alternatives plus conventionnelles sur une période de cinq ans. Sept ans plus tard et de nombreuses entreprises clientes plus tard, chaque nouveau client parvient encore à nous surprendre, d’une manière ou d’une autre, avec une nouvelle tournure dans leur supply chain, que nous n’aurions jamais réussi à embrasser avec une approche classique d’entreprise. La programmabilité était nécessaire, mais Python n’était pas la solution dont nous avions besoin.