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 offrir quelque chose d’approchant la grandeur en ce qui concerne l’optimisation de la supply chain. Nous avons fait de notre mieux, mais cela ne suffisait pas. Peu importe le nombre de fonctionnalités que nous incorporions 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’alors. Les défis de la supply chain sont tout simplement trop divers et trop chaotiques pour pouvoir être encapsulés dans un nombre raisonnable de menus, boutons et options.

En réalité, la majorité de nos concurrents reconnaissent cette situation et ont opté pour la création de produits logiciels comportant un nombre insensé de menus, boutons et options, le tout dans une tentative désespérée de faire face à tous les défis de la supply chain. Malheureusement, cette voie conduit à des monstruosités logicielles qui se transforment en spectaculaires échecs lorsqu’elles sont déployées à grande échelle. Je désigne cet anti-modèle sous le nom de Non-Euclidian Horror.

Ainsi, confrontés à une catégorie de problèmes – c’est-à-dire les défis de la supply chain – qui ne pouvaient tout simplement pas être résolus par une seule application, nous avons commencé, en partie par hasard¹, à aborder le méta-problème : comment fournir des applications sur-mesure dans lesquelles chaque application serait dédiée à la résolution d’un problème unique pour une situation donnée, par exemple l’optimisation du reapprovisionnement pour une entreprise spécifique.

Fournir des logiciels sur-mesure pour les entreprises n’est pas une nouveauté. L’industrie du logiciel a commencé ainsi dans les années 60, puis a é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 tendent à présenter de nombreuses propriétés indésirables comparativement aux solutions en boîte : des investissements initiaux plus élevés, des mises en place longues, des coûts de maintenance plus importants, des risques accrus, etc.

Pourtant, l’expérience que j’avais acquise durant les premières années de Lokad indiquait qu’en ce qui concerne l’optimisation de la supply chain, les logiciels sur-mesure présentaient un avantage clé : ils donnaient réellement des résultats excellents. En effet, alors que notre application originale se contentait, au mieux, de fournir des résultats passables² quelle que soit la précision des prévisions, ces prototypes obtenaient fréquemment des résultats excellents. De plus, l’unique astuce résidait dans la spécialisation extrême du logiciel destiné au problème à résoudre.

Après avoir épuisé ce qui semblait être toutes les alternatives, nous avons conclu que fournir des applications sur-mesure était la seule voie possible. Cependant, la scalabilité – comment fournir de nombreuses applications – et la maintenabilité – comment maintenir les coûts de maintenance sous contrôle – étaient deux préoccupations majeures. Premièrement, nous devions choisir un langage de programmation. À l’époque, nous avons envisagé de nombreuses options : R, Python, JavaScript, Lua, C#, … ainsi que le développement de notre propre langage de programmation spécifique au domaine (DSL), qui serait plus tard connu sous le nom d’Envision. Discuter des avantages et inconvénients de toutes ces options aurait été quelque peu fastidieux³, d’où, pour plus de clarté, la discussion s’est centrée sur le choix entre Python et Envision ; Python étant le concurrent le plus sérieux face à l’option de développer notre propre DSL.

Python était attrayant en raison de sa simplicité et de tout son riche écosystème de bibliothèques tierces, notamment dans le domaine du machine learning⁴. C’était également une option à faible coût pour Lokad : puisque Python, et pratiquement toutes ses bibliothèques populaires, sont open source, nous n’aurions eu qu’à reconditionner un sous-ensemble restreint de Python, en sélectionnant quelques dizaines de paquets triés sur le volet, et le tour était joué. La majeure partie du travail chez Lokad aurait consisté à offrir une expérience PaaS autour de Python à la manière de Heroku, mais 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 d’attendre d’un analyste métier – qui sera plus tard connu sous le nom de Supply Chain Scientist – travaillant 1 jour par semaine pendant 6 mois qu’il livre une application de qualité production pour résoudre un défi supply chain mission critique, comme le reapprovisionnement, pour une entreprise de 10M $ ? 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 logiciels. En effet, Python, comme tout langage de programmation complet, expose une multitude d’intricacités techniques à quiconque écrit du code en Python. Bien que le rôle du Supply Chain Scientist ait été formalisé ultérieurement, nous avions très tôt l’intuition que, même en considérant des personnes intelligentes et talentueuses, attendre d’elles qu’elles soient à la fois expertes en ingénierie de la supply chain et en ingénierie logicielle était trop demander. Nous avions besoin de capacités programmatiques accessibles à un large spectre de personnes ayant une mentalité technique, et non uniquement aux ingénieurs logiciels professionnels.

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

• Les objets peuvent être null, les dates peuvent être absurdement éloignées dans le passé ou dans le futur, NaN peut se propager joyeusement à travers votre pipeline de données, les chaînes de caractères peuvent devenir absurdement longues… Dans la supply chain, ces « caractéristiques » ne sont rien d’autre que des problèmes attendant de survenir.
• Les éléments orientés objet (c’est-à-dire les classes) sont voués à être mal utilisés⁵, et il en va de même pour les exceptions personnalisées ou les Regex. La simple présence de ces éléments est, au mieux, une distraction malsaine.
• De nombreuses opérations basiques telles que l’analyse de fichiers tabulaires disparates (y compris un classeur Excel) ne font pas partie du langage, et nécessitent de traiter avec de nombreux paquets disparates, chacun ayant ses propres subtilités techniques.

Aucune de ces catégories de problèmes techniques ne peut être éliminée de Python sans paralyser le langage lui-même. Envision, en tant que langage de programmation, est accessible aux spécialistes de la supply chain (contre spécialistes logiciels), uniquement grâce à son approche d’une précision chirurgicale sur les problèmes prédictifs d’optimisation de la supply chain.

Imaginez la dernière fois où vous avez dû effectuer des calculs avec un classeur Excel, et imaginez-vous dicter toutes les modifications apportées à ce classeur par téléphone sans pouvoir le voir vous-même. Voilà à quoi ressemble une initiative d’optimisation de la supply chain menée par des praticiens, mais mise en œuvre par des ingénieurs logiciels (non spécialistes de la supply chain). Le monde des affaires passe un temps considérable à transmettre ce qu’il souhaite à l’informatique ; et l’informatique consacre un temps considérable à essayer de comprendre ce que souhaite le monde des affaires. 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 livrer une initiative d’optimisation de la la Supply Chain Quantitative multiplie les coûts d’au moins un facteur 5, peu importe l’agilité et le talent de l’équipe de développement.

Deuxièmement, les coûts de maintenance des prototypes Python précipités atteignent des sommets. En dehors de l’industrie du logiciel, peu de gens se rendent compte que l’ingénierie logicielle⁶ consiste principalement à maintenir les coûts de maintenance sous contrôle. 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, des processus imparfaits et en constante évolution doivent être documentés et modélisés, les métriques d’optimisation reflètent une stratégie d’entreprise en perpétuel changement, etc. En conséquence, quel que soit le logiciel écrit pour réaliser l’optimisation de la supply chain, il intègre toujours une dose massive de complexité spécifique au domaine, se contentant de faire face à ce que le monde nous lance.

Pourtant, le temps presse. Il ne sert à rien de disposer du plan parfait pour la planification de production de l’année dernière. En règle générale, on peut considérer qu’au jour où le prototype logiciel commence à fonctionner, il sera mis en production en l’espace de quelques semaines, que ce prototype soit bien ou mal rédigé.

Penser que la haute direction approuvera un délai de 6 mois pour réécrire le prototype afin de le rendre de qualité production d’un point de vue maintenance relève du souhait irréaliste. Pourtant, mettre en production un prototype Python précipité est la recette d’une surcharge de maintenance épique, un combat de tous les instants contre un flot incessant de bugs qu’il faudra colmater en urgence 24 heures sur 24, 7 jours sur 7.

Ainsi, la seule façon pratique de maintenir la production dans un état correct 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 à la compilation : lorsqu’on traite plusieurs téraoctets de données, il devient très fastidieux d’attendre des heures avant de se rendre compte qu’un calcul ne se terminera jamais. Une consommation mémoire limitée garantie à la compilation : lutter contre des erreurs d’épuisement de mémoire dans le lot de production nocturne n’est guère amusant et, en pratique, perturbe gravement les opérations.
• Lectures et écritures atomiques : Envision empêche, par conception, les lectures et écritures concurrentes au sein du système de fichiers, même lorsque des fichiers sont transférés via FTP pendant l’exécution des scripts. Le système de fichiers qui supporte Envision est à peu près un Git conçu pour des fichiers plats giganormes. Sans un versionnage adéquat des données, de nombreux bugs se transforment en heisenbugs : le temps qu’une personne se penche sur le problème, les données ont été actualisées, et le problème ne peut plus être reproduit.
• Exécution ambient scale-out du programme sur un cloud de ressources informatiques, éliminant tous les obstacles à la parallélisation qui deviennent 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, s’appuyant largement sur la liaison tardive, fournit excessivement 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 en rien satisfaisantes pour l’optimisation de la supply chain.

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

Défense en profondeur : Dès que quelqu’un commence à écrire du code dans votre organisation, à moins que des précautions très particulières ne soient prises⁷, son code devient une responsabilité immédiate du point de vue de la sécurité IT. Avec Python, il est pratiquement possible de faire n’importe quoi sur la machine exécutant le script Python. Mettre Python correctement en sandbox relève en pratique d’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 textes plats simples comme les CSV sont vulnérables aux attaques par injection. Envision offre un niveau de sécurité qui ne peut tout simplement pas être reproduit avec Python. Les violations de données sont en hausse, et disséminer du code Python partout ne va rien apporter à la sécurité IT.

Performance transparente : Si un programme est excessivement lent à s’exécuter, alors ce programme ne devrait même pas se compiler en premier lieu⁸. Si un programme est réduit 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 viser non pas une machine donnée, mais un cloud de ressources informatiques, offrant une parallélisation automatique pilotée par les données. Envision va très loin dans la fourniture par défaut de toutes ces propriétés sans aucun effort de codage. En revanche, il nécessite une utilisation massive de bibliothèques spécialisées en Python pour même commencer à approcher de telles propriétés.

Mise à niveau transparente : L’état de l’art est une cible mouvante en ce qui concerne le logiciel. En 2010, la meilleure boîte à outils de machine learning était SciPy (disons-le). En 2013, c’était scikit. En 2016, c’était Tensorflow. En 2017, c’était Keras. En 2019, c’était PyTorch. Il est dit en ingénierie logicielle que l’on peut dater l’année de naissance de tout 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 de multiples dépendances qui ne vieillissent pas bien. En revanche, avec Envision, nous exploitons largement des réécritures de code automatisées¹⁰ pour maintenir les scripts “legacy” à jour avec un langage en constante évolution.

Pile packagée : Les scripts Python ne peuvent pas vivre dans le vide¹¹. 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 VM Linux dans le cloud). Un planificateur est nécessaire pour orchestrer le pipeline de données (par exemple, AirFlow). Une couche de stockage colonnes distribuée est nécessaire pour la préparation des données (par exemple, Spark). Une boîte à outils de machine learning est nécessaire pour l’analytique prédictive (par exemple, TensorFlow). Une boîte à outils d’optimisation est nécessaire pour traiter les problèmes combinatoires de supply chain (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 supply chain doivent pouvoir surveiller ce qui se passe (par exemple, une interface web). Les droits d’accès doivent être appliqués (par exemple, Active Directory), etc. Envision rationalise tout cela en une seule méta-application, éliminant le fardeau de l’assemblage de dizaines de pièces logicielles pour fournir même l’application la plus basique.

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

• La performance de calcul est médiocre, et il est très difficile de faire passer chaque calcul par la bibliothèque appropriée (par exemple, NumPy) afin d’éviter des performances abysmales lors des tâches de traitement de données. De plus, l’utilisation de plusieurs bibliothèques tend à créer beaucoup de friction lorsque les données doivent être transférées de l’une à l’autre.
• La performance mémoire est également mauvaise, et en particulier, le ramasse-miettes par comptage de références de Python est datée - et tous les langages de programmation plus récents comme Java, C# ou JavaScript utilisent le traçage à la place. Lorsqu’on traite des tâches intensives en mémoire avec du big data, cela nuit.
• La gestion des packages en Python a été un désordre pendant longtemps, et il faut un spécialiste des packages pour y parvenir correctement. De plus, ce problème a été aggravé par les mises à niveau linguistiques à fort frottement.
• La plupart des quelques vérifications de correction ne s’effectuent qu’à l’exécution, lorsque le programme est lancé, ce qui constitue une source de frustration sans fin lors du traitement des données. Des problèmes évidents ne se manifestent qu’après plusieurs minutes d’exécution, réduisant ainsi la productivité.

En conclusion, bien que Python soit formidable (il l’est), ce n’est pas une réponse satisfaisante pour l’optimization de la supply chain. Construire et maintenir une application de machine learning de niveau production en Python est tout à fait possible, mais les coûts sont significatifs, et à moins que votre entreprise ne soit prête à disposer d’au moins une petite équipe d’ingénierie logicielle dédiée à la maintenance de cette application, l’ensemble ne produira pas des résultats satisfaisants pour votre supply chain.

Développer 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 dixième choix. C’était plutôt la seule solution opérationnelle que nous avions après avoir épuisé une longue liste d’alternatives plus conventionnelles pendant cinq ans. Sept ans plus tard et après de nombreuses entreprises clientes, chaque nouveau client parvient encore à nous surprendre, d’une manière ou d’une autre, avec un nouveau rebondissement dans leur supply chain, que nous n’aurions jamais pu envisager avec une approche enterpriseware classique. La programmabilité était nécessaire, mais Python n’était pas la solution qu’il nous fallait.