00:00:00 Histoire de la fondation de Lokad et premières années
00:02:31 Idées reçues sur l’optimisation de la supply chain
00:04:31 Les théories existantes de la supply chain ne fonctionnaient pas
00:06:32 Le paradoxe des échecs de prévision
00:08:33 Comment “prédire rien” a battu la concurrence
00:10:25 Le défi de rejeter les idées établies
00:12:00 Le passage aux prévisions probabilistes
00:14:07 L’importance des scénarios de demande extrême
00:16:32 La complexité de l’intégration des données d’entreprise
00:20:55 Pourquoi les modèles de supply chain sur papier échouent
00:27:30 Les problèmes d’ingénierie dans l’adoption de l’IA en entreprise
00:35:00 L’impact du COVID-19 sur les supply chains
00:42:49 Les LLM sont basés sur du texte, pas sur les mathématiques
00:50:25 L’évolution parallèle de l’industrie financière
01:09:00 Questions & réponses et remarques finales
Résumé
Joannes Vermorel, CEO et fondateur de Lokad, a donné une conférence en français, partageant son parcours dans la Supply Chain management. Vermorel a raconté la fondation de Lokad après avoir obtenu son diplôme de l’École Normale Supérieure et avoir réorienté son attention de la bioinformatique vers les défis de la Supply Chain. Il a évoqué le développement d’Envision, le langage de programmation de Lokad, et l’évolution de l’entreprise depuis 2007. Vermorel a critiqué les théories traditionnelles de la Supply Chain, les comparant à l’astrologie, et a souligné l’importance de remettre en cause le consensus. Il a mis en avant le succès de Lokad grâce aux méthodes probabilistes et l’impact du COVID-19 sur la robotisation. Vermorel a prédit l’obsolescence des rôles traditionnels et a encouragé les étudiants à impulser la révolution de l’industrie.
Résumé étendu
Dans une conférence donnée aux étudiants en français, Joannes Vermorel, CEO et fondateur de Lokad, a partagé son parcours et ses réflexions sur le monde de la Supply Chain management et l’évolution de son entreprise. Vermorel a commencé en se présentant et en racontant les origines de Lokad, une entreprise qu’il a fondée dès l’obtention de son diplôme de l’École Normale Supérieure. Au départ, Vermorel avait tenté de poursuivre une thèse en bioinformatique mais s’est rapidement rendu compte que le domaine était déjà saturé de talents. Par hasard, il est tombé sur les défis de la Supply Chain, qui sont devenus son nouveau centre d’intérêt.
Vermorel a exprimé sa surprise et sa joie de voir des étudiants de Centrale utiliser Envision, un langage de programmation qu’il a créé pour l’optimisation de la supply chain. Il a raconté le développement d’Envision, notant que le premier compilateur qu’il avait écrit a rapidement été remplacé par une version supérieure créée par Victor Nicolet, le CTO de Lokad. Depuis, Envision a beaucoup évolué, l’entreprise étant désormais sur le point de sortir la version 6.
Le parcours de Lokad a commencé en 2007, l’entreprise ayant été officiellement fondée en 2008. Cependant, Envision n’a été introduit qu’en 2013, soit cinq ans après la création de Lokad. Vermorel a expliqué que la décision de créer un nouveau langage de programmation est survenue après avoir épuisé toutes les autres alternatives. Au départ, il pensait que la supply chain était un domaine bien établi avec des décennies de littérature et de nombreux concurrents tels que SAP, Oracle, IBM et Microsoft. Il croyait que la clé du succès serait de reconditionner les théories établies de la supply chain sous forme d’applications web, profitant du passage des applications client-serveur aux solutions basées sur le cloud computing.
Malgré sa confiance initiale, Vermorel a rapidement découvert que les théories et modèles établis ne fonctionnaient pas comme prévu. Il a raconté une expérience particulièrement absurde en 2011, où Lokad avait remporté un benchmark en soumettant zéro prévision, ce qui a surpassé la concurrence de 20% en précision. Cette expérience a amené Vermorel à remettre en question la validité des théories classiques de la supply chain, les comparant à de l’astrologie plutôt qu’à de l’astronomie.
Vermorel a souligné l’importance de remettre en cause le consensus en science, notant que l’histoire regorge d’exemples de croyances largement acceptées mais finalement incorrectes. Il a conclu que, bien que la supply chain elle-même soit un domaine légitime, les théories classiques qui la sous-tendent étaient erronées. Cette prise de conscience l’a poussé à explorer des approches alternatives, telles que les prévisions biaisées et les prédictions quantiles, qui se sont révélées plus efficaces.
L’approche de Lokad a évolué pour adopter des méthodes probabilistes et programmatiques, s’éloignant des modèles traditionnels qui ne parvenaient pas à aborder les complexités des problèmes réels de la supply chain. Vermorel a mis en avant l’importance de disposer d’un langage de programmation robuste, adapté à ces défis, critiquant l’utilisation de langages généralistes comme Python, qui aboutissaient souvent à des initiatives infructueuses en raison de divers problèmes techniques.
La conférence a également abordé l’impact de la pandémie de COVID-19, qui a accéléré la robotisation des supply chains. Vermorel a noté que les solutions de Lokad se montraient efficaces à grande échelle, gérant des stocks pour une valeur de milliards d’euros avec une intervention humaine minimale. Ce changement reflète la transition observée dans l’industrie financière, où le trading est devenu principalement algorithmique.
Vermorel a discuté de l’avenir de la Supply Chain management, prédisant que les rôles traditionnels de gestionnaires de stocks et de demand planners deviendraient obsolètes à mesure que davantage d’entreprises adopteraient des processus automatisés de prise de décision. Il a encouragé les étudiants à être proactifs dans le déclenchement de cette révolution plutôt que de l’observer passivement.
En réponse aux questions des étudiants, Vermorel a expliqué que les entreprises fortement axées sur la technologie pourraient internaliser les solutions de Lokad, tandis que d’autres continueraient probablement à externaliser ces services. Il a également abordé les limites des grands modèles de langage (LLMs) comme ChatGPT, notant leur incapacité à apprendre et à mémoriser.
Vermorel a conclu en réfléchissant à l’irrationalité des marchés et à la persistance des projets ratés dans l’industrie de la supply chain. Il a partagé des anecdotes sur des concurrents qui, malgré leurs échecs passés, ont levé à plusieurs reprises d’importantes sommes, soulignant la nature chaotique du marché. Malgré ces défis, Vermorel a exprimé sa fierté quant aux réalisations de Lokad et au succès inattendu d’Envision auprès d’étudiants d’institutions prestigieuses telles que Centrale. Il a invité les étudiants à envisager de rejoindre Lokad, soulignant les efforts constants de recrutement de l’entreprise.
Transcription complète
Le discours original en français a été traduit en anglais.
Joannes Vermorel: Permettez-moi de me présenter : je suis Joannes Vermorel, fondateur de Lokad. J’ai créé l’entreprise dès que j’ai fini mes études. J’étais à l’École Normale Supérieure, j’ai commencé un doctorat en bioinformatique, mais en fin de compte, tant de personnes faisaient des choses intéressantes en bioinformatique qu’elles n’avaient probablement pas besoin de moi. Et par hasard, je suis tombé sur ces problèmes de supply chain. Je suis très heureux de voir que vous utilisez Envision aujourd’hui. C’est quelque chose de vraiment incroyable pour moi de me retrouver devant des étudiants de Centrale à parler de ce langage. C’est quelque chose que je n’aurais jamais imaginé à l’époque où j’ai créé Envision, il y a environ douze ans.
J’ai écrit le premier compilateur d’Envision, puis Victor Nicolet—le CTO de Lokad—a supprimé celui-ci et a rapidement écrit le deuxième compilateur, qui était bien meilleur. Et maintenant, vous utilisez essentiellement la version 5, alors que la version 6 est sur le point d’être lancée. Le langage a beaucoup évolué. Mais ce sur quoi vous avez travaillé—ce morceau que vous avez vu—n’était pas du tout le point de départ de Lokad. Il est arrivé assez tard en fait. Lokad est un projet qui a débuté en 2007 et a été incorporé en 2008, alors qu’Envision date d’environ 2013. Ainsi, quand Envision est arrivé, l’entreprise avait déjà environ cinq ans.
L’idée de créer un langage est venue après avoir épuisé toutes les autres alternatives ; ce n’était pas le plan du fondateur visionnaire dès le départ—simplement parce que tout le reste que nous avons essayé avait échoué.
Pour vous donner une idée de ce qui est si surprenant dans la supply chain : lorsque j’ai lancé Lokad en 2008, j’estimais que la supply chain était un domaine bien établi. Après tout, il existe 60 ou 70 ans de littérature à ce sujet, littéralement des millions d’articles. Si vous tapez “supply chain management” sur Amazon, vous obtenez—j’ai vérifié—environ 10 000 livres actuellement disponibles sur le sujet. Au fil des décennies, bien d’autres ont été publiés, mais ces 10 000 restent ceux encore en vente aujourd’hui. C’est un domaine extrêmement bien documenté.
Quand j’ai commencé, j’ai vu de grands concurrents aux grands noms : SAP, Oracle, IBM, voire Microsoft—de grands acteurs dans la supply chain. Si vous additionnez le chiffre d’affaires total de vos concurrents, cela représente un demi-trillion de dollars. C’est considérable. Mon intuition initiale—complètement erronée comme il s’est avéré—était que je pourrais prendre les théories établies de la supply chain et simplement les reconditionner sous forme d’une application web. C’était en 2008, et tous les enterprise software passaient des applications dites « épaisses client » que vous installez sur votre PC, aux applications dites « légères client », c’est-à-dire des applications web. Il y avait donc cette opportunité de reconstruire les logiciels de supply chain sous forme d’application web, éventuellement avec une hébergement en cloud computing. Lokad a migré vers le cloud très tôt. Cela aurait pu nous donner une longueur d’avance sur les grandes entreprises encore accrochées aux systèmes client plus anciens et plus lourds. Et comme il existe littéralement des livres entiers expliquant comment optimiser les supply chains—comme le manuel du MIT, le manuel de Stanford, le manuel de Caltech—je les ai lus, tous ces volumes de 1 000 pages écrits par deux ou trois professeurs avec toutes les équations.
J’ai ensuite codé ces approches—et rien n’a fonctionné. Fait intéressant, cela n’a pas empêché Lokad de croître ou d’avoir des clients. On pourrait penser que pour gagner de l’argent en tant que startup, il faut un produit qui fonctionne réellement, mais dans le logiciel d’entreprise, vous pouvez vendre quelque chose qui ne fonctionne pas du tout, et tout de même trouver des clients. Cela peut paraître étrange, mais c’est ainsi. En réalité, s’il existe un gros problème que l’entreprise souhaite résoudre, il y a un budget pour essayer de le résoudre. Ce budget n’est peut-être pas énorme—surtout si votre produit ne fonctionne pas réellement—mais pour une startup, ces sommes peuvent sembler très importantes. Si un géant comme Carrefour met 100 000 euros sur la table « juste pour voir », ce n’est rien pour Carrefour, mais c’est beaucoup pour une petite entreprise.
Ainsi, en profitant de cette asymétrie, j’ai commencé et tenté de mettre en œuvre ces théories standards de la supply chain : prévision des séries temporelles, stocks de sécurité, l’optimisation du taux de service, etc. Rien de tout cela n’a fonctionné ; aucun d’entre eux. Nous avons eu ces discussions assez schizophreniques avec les clients : ils disaient, « Vous devez avoir codé la formule du stock de sécurité de manière incorrecte », alors nous repassions, prenions littéralement les valeurs des tableaux dans les manuels, recalculions les paramètres—et c’était exactement comme indiqué. La théorie était implémentée correctement, mais le résultat était totalement absurde.
Je pense que le comble de l’absurde est survenu à l’été 2011. Nous avons participé à un important appel d’offres avec une demi-douzaine de fournisseurs de logiciels, la moitié étant européens, l’autre moitié américains. Lokad était parmi les Européens. Le cas, si je me souviens bien, concernait une dizaine de supermarchés, 5 000 SKUs par supermarché, avec la nécessité de prévoir quelques jours à l’avance car ces supermarchés étaient réapprovisionnés peut-être deux ou trois fois par semaine. Le client utilisait un critère d’erreur de backtesting sur des prévisions quotidiennes au niveau des produits pour chaque magasin—essentiellement l’erreur absolue entre la prévision et la réalité. Lokad a fini par remporter ce benchmark—avec une précision meilleure de 20%, écrasant absolument la concurrence. Ma méthode secrète ? J’ai renvoyé des zéros. Zéro pour tout. Grâce à ma « prévision zéro », j’ai également battu tout le monde en rapidité de calcul : renvoyer des zéros est extrêmement rapide. Et j’ai obtenu une précision de prévision 20% supérieure à celle des autres.
Évidemment, c’était complètement absurde. Mais si vous considérez l’approche recommandée par tous les manuels de supply chain et le processus standard du client, cela aboutissait à une absurdité totale. La conclusion que j’en ai tirée était assez déconcertante. Nous avions une entreprise rentable et en croissance, mais j’ai été forcé de réaliser que je venais peut-être de tomber sur un mécanisme. Vous pouvez lancer quelque chose, cela rapporte de l’argent, mais c’est du pur non-sens. Peut-être qu’au début, vous êtes tout simplement trop inexpérimenté pour vous en rendre compte. Mais une fois que vous vous en rendez compte, continuez-vous ? Lorsque vous obtenez votre diplôme et découvrez que ce que vous faites est absurde, poursuivez-vous ? Cela a déclenché un questionnement profond. La supply chain pourrait-elle n’être que de l’astrologie—du genre voyance, et non de l’astronomie ?
Finalement, je suis parvenu à la conclusion que la supply chain en tant que domaine est réelle, mais que la théorie standard de la supply chain est fondamentalement de l’astrologie. C’était le problème. Il est très difficile d’accepter que 70 ans de recherche, plus d’un million d’articles, des milliers de professeurs, puissent tous se tromper. Imaginez l’arrogance intellectuelle nécessaire. Si vous consultez quatre médecins différents, chacun vous disant que vous avez le même diagnostic, à quel moment dites-vous qu’ils ont tous tort et que vous avez raison ? Mais la science ne fonctionne pas sur le consensus. Mille personnes peuvent être d’accord sur quelque chose et se tromper. L’histoire de la science regorge d’exemples : des consensus extrêmement larges sur des idées qui se sont avérées folles. Certains spécialistes de l’histoire des sciences affirment même que la moitié de ce qu’une société croit à un moment donné est fausse ; la difficulté réside dans le fait de savoir laquelle.
Ainsi, Lokad est arrivé à cette conclusion à partir du benchmark : la méthode dominante était absurde. Nous devions chercher autre chose. Notre grande percée est survenue début 2012, en s’attaquant aux prévisions biaisées avec ce qu’on appelle quantile forecasts. À l’époque, j’avais des clients employant 50 personnes à plein temps uniquement pour éliminer le biais. Ils m’ont alors demandé, “Why on earth would you want a biased forecast, given we pay folks to un-bias them?” Ils étaient assez alarmés, car la nouvelle méthode ajoutait tellement de biais qu’ils n’auraient jamais pu l’enlever manuellement. Mais si j’appelle cela “quantile forecasting,” cela paraît plus scientifique que “biased forecasting.” En réalité, cependant, une quantile forecast n’est qu’une prévision biaisée.
Nous avons testé cette approche avec notre premier client du e-commerce. Du jour au lendemain, nous sommes passés de résultats absurdes — comme prévoir zéro pour tout — à quelque chose de médiocre mais au moins quelque peu sensé. Cela peut ne pas sembler incroyable, mais passer de l’absurdité totale à la simple médiocrité fut un grand pas en avant.
Cela nous a ensuite conduits à revoir toutes les hypothèses de supply chain présentes dans les manuels — remettant en cause chaque fondement, qui s’est avéré très fragile, et fondamentalement erroné. Le quantile forecasting n’est qu’une version simplifiée de cela. C’est un outil statistique qui se concentre spécifiquement sur les extrêmes. D’un point de vue économique, dans la supply chain, ce sont les extrêmes qui engendrent des pertes d’argent : une demande exceptionnellement élevée qui crée une rupture de stock, une demande exceptionnellement faible qui crée un surstock, des lead times exceptionnellement longs qui ruinent vos plans, etc. Ce n’est jamais le centre de la distribution qui vous nuit réellement ; ce sont les queues. Une quantile forecast est un outil qui se focalise sur ces extrêmes. Une version améliorée est la prévision probabiliste — ce sur quoi vous avez travaillé — où vous obtenez une distribution de probabilité complète. En 2012, nous avons commencé avec les quantile forecasts parce que c’était plus simple en termes de mathématiques, de statistiques et d’informatique. Gérer une distribution de probabilité sur des millions de SKUs est bien plus lourd que de générer un nombre de prévision unique par SKU.
Pendant ce temps, Envision — qui avait été initialement développé pour quelque chose de totalement différent, un projet interne dont le nom de code était “Priceforge” pour la tarification — s’est avéré parfait pour adopter la nouvelle approche. Avant cela, l’idée de Lokad était de construire un logiciel standard de supply chain avec des menus, des boutons et des options, comme c’est typique dans les logiciels d’entreprise. Mais c’était le chaos du point de vue de l’éditeur : à mesure que vous ajoutiez des fonctionnalités, le mapping des données de l’environnement du client vers vos structures de données devenait un véritable cauchemar d’ingénierie.
Pourquoi ? Parce que les architectures de données des clients sont toujours uniques. L’ERP d’un client peut comporter 10 000 tables, chacune avec 50 champs, dont beaucoup ne sont pas documentés et utilisés de manière inhabituelle. En réalité, ils peuvent avoir deux ou trois ERP, plus un WMS, plus une plateforme de le e-commerce… L’écosystème est compliqué. Aucune entreprise n’a les mêmes définitions de données. Même quelque chose d’apparemment simple comme “order date” peut comporter 20 définitions différentes : la date de création de l’enregistrement, la date à laquelle le client a confirmé la commande, la date à laquelle vous l’avez confirmée, la date à laquelle le prestataire de paiement l’a autorisée, la date d’expédition de la commande, etc. Multipliez cela par un millier d’autres champs de données potentiels.
Si vous créez un logiciel “classique” avec des définitions fixes pour le produit, le SKU, les variantes, le fournisseur, l’emplacement, etc., ces définitions correspondent rarement à la réalité du client. Même dans l’habillement, par exemple, une entreprise peut définir les variantes uniquement en termes de couleur et de taille, tandis qu’une autre peut y inclure la composition du tissu. Ou dans l’alimentation, vous pouvez avoir “expiration date” signifiant soit le jour où il est formellement impossible de le vendre, soit le jour où il ne peut plus être exposé en magasin. Les subtilités sont infinies.
C’est pourquoi les théories standards de la supply chain se sont révélées inadéquates. Il nous fallait quelque chose de nouveau : une approche programmatique. C’est un aspect que les manuels de supply chain n’abordent jamais. Les modèles prêts à l’emploi ne suffisent pas, car le monde réel ne correspond jamais parfaitement à ces modèles. Il y a toujours quelque chose — quantité de commande minimale, contraintes d’expiration, contraintes de planning d’expédition. Les contraintes de chaque entreprise sont uniques. Nous avons donc compris que la solution devait être programmatique, et non une formule statique. La question est alors devenue : quel est le bon programming paradigm pour la supply chain ?
En 2012, certains pouvaient dire, “Why not just use Python?” En effet, à l’époque, c’était exactement ce que faisaient tous mes clients américains du e-commerce. Presque toutes les initiatives de data science que j’ai vues à cette époque échouaient à cause de Python (ou cela aurait pu être Java, C# ou, plus tard, Julia — c’est le même problème). Le schéma était le suivant : en trois semaines, une équipe de data science construisait un prototype impressionnant pour un problème de supply chain. Ensuite, ils voulaient le mettre en production, et un an plus tard, ce n’était toujours pas le cas ; la direction perdait patience, annulait le projet, et c’était fini.
Pourquoi cela a-t-il échoué ? Mort par mille petits coups : NullReferenceException, OutOfQuotaException, problèmes de concurrence, packages incompatibles, brèches de sécurité, ransomware sur votre environnement, etc. Rien de tout cela n’est directement lié au problème de supply chain lui-même. Le problème fondamental est que si vous utilisez un langage à usage général dans un grand environnement de production, votre surface d’attaque pour les problèmes est immense. Par exemple, si votre code peut écrire sur le système de fichiers, vous pouvez accidentellement corrompre l’environnement qui héberge votre code — ce qui est facile à faire lorsque vous traitez des gigaoctets de données en parallèle. Peut-être qu’un fichier est verrouillé par un processus, ou qu’un disque manque d’espace, et ainsi de suite. Ces situations se produisent inévitablement en pleine nuit, sans que personne ne soit là pour y remédier immédiatement. Puis, au matin, le client est furieux parce qu’il s’attendait à ce que le système se termine à 2 h du matin, mais il est tombé en panne à minuit.
Dans les démonstrations de data science, vous avez généralement un babysitter qui lance le script, donc s’il plante, il le répare. Mais l’automatisation de la supply chain dans le monde réel doit fonctionner de manière autonome chaque jour. Même les temps d’exécution peuvent fluctuer de 20 minutes à deux heures, ce qui perturbe la production. C’était le problème en 2012 : ces initiatives de data science échouaient en production non pas à cause de la logique de la supply chain, mais en raison de la grande complexité des langages à usage général.
Tout cela a conduit Lokad à réaliser qu’il nous fallait un environnement programmatique à la fois sûr et spécialisé, capable de gérer des opérations quotidiennes à grande échelle sans babysitting fragile. De plus, une fois que nous avons compris qu’il était nécessaire d’effectuer des prévisions avancées (probabilistes, quantile, etc.), Envision a été configuré pour traiter ces workflows comme des citoyens de première classe. Par exemple, si vous souhaitez faire de la differentiable programming pour le machine learning, dans un langage à usage général, vous intégrez un autre “mini-langage” comme PyTorch pour cela. Vous vous retrouvez alors avec Python plus un segment de code PyTorch, et il est facile de faire des erreurs, car votre code PyTorch est essentiellement une chaîne non compilée. Il en va de même pour le mélange de requêtes SQL dans votre code Python. Tout est sous forme de chaînes, de sorte que vous ne découvrez vos fautes de frappe qu’au moment de l’exécution. Envision, en revanche, peut traiter ces fonctionnalités comme des éléments intégrés avec des vérifications de compilation.
L’approche de Lokad a évolué en parallèle avec des avancées telles que le deep learning — où vous n’avez plus seulement une bibliothèque de modèles préemballés, mais vous composez vous-même votre modèle de manière programmatique. TensorFlow est essentiellement un langage pour construire des graphes de calcul. Vous n’êtes pas limité à un “catalog” de modèles ; vous construisez des structures. Envision peut également intégrer ces idées de manière native. Par exemple, nous avons récemment travaillé sur l’optimisation stochastique. Quelqu’un ici sait ce que c’est ? C’est l’optimisation mathématique d’une fonction dont le résultat est incertain — comme décider du nombre d’unités à acheter lorsque la demande future est inconnue. C’est un défi classique de supply chain. Vous avez vu des versions plus simples avec des contraintes minimales, mais les entreprises réelles font face à une multitude de contraintes : minimums de commande, fill rates, contraintes de catégorie ou calendriers compliqués. De surcroît, votre fonction coût/bénéfice est incertaine. Ce sont donc des concepts programmatiques avancés.
Bref, Envision n’a cessé d’ajouter des fonctionnalités. À ce jour, nous sommes également à l’aube d’une autre révolution : les large language models (LLMs). Vous connaissez probablement ChatGPT. Peut-être que certains d’entre vous l’utilisent pour faire leurs devoirs. (Je ne vous note pas, donc vous pouvez l’avouer !) Ou même que vous payez pour la version pro. Ce qui est intéressant pour nous, c’est que Lokad a une culture de l’écriture, ce qui est assez inhabituel pour une entreprise de supply chain. Nous nous appuyons sur le texte à deux niveaux. D’abord, nous avons le code Envision lui-même, qui encode littéralement ce que nous faisons. Nous ne voulons pas d’un processus qui génère des commandes recommandées dans Excel, puis que quelqu’un les modifie manuellement. Notre objectif est que les chiffres finaux soient générés automatiquement sans intervention manuelle. Et si des modifications sont nécessaires — ce qui arrive parfois, au début — ces modifications sont enregistrées dans un workflow afin que nous puissions en discuter avec le client : “Why did you modify what was generated? What might we change so manual edits are no longer needed?” Ou parfois, nous constatons que les modifications n’étaient pas réellement utiles, ce qui nous permet d’intégrer ce savoir.
Ensuite, nous disposons d’un second artefact textuel, le JPM ou Joint Process Manual, qui explique le “pourquoi.” C’est notre document de référence pour les transferts et pour donner au client une vue d’ensemble de l’initiative en langage clair — sans qu’il ait à lire directement le code Envision. Nous avons donc une couche de code qui décrit le “quoi” et une couche documentaire séparée qui explique le “pourquoi.”
Cela correspond parfaitement aux LLMs, car ces derniers traitent le texte. Ils ne sont pas très doués avec de simples données numériques brutes. Si vous déversez une énorme table dans ChatGPT, vous n’obtiendrez pas une régression sensée. ChatGPT ne peut que générer un morceau de code Python qui réaliserait la régression. Les LLMs sont eux-mêmes d’immenses modèles de prédiction du token suivant ; ils ne sont pas conçus pour l’arithmétique. D’où les blagues sur l’échec de ChatGPT en mathématiques élémentaires. Mais si vous leur fournissez du code ou des instructions textuelles, ils excellent en manipulation et en génération.
Voilà donc où se situe Lokad : nous disposons d’automatisations avancées de la supply chain capables de fonctionner pendant des mois sans intervention humaine — quelque chose qui a été prouvé lors des confinements de 2020–2021, quand bon nombre de nos clients ont envoyé leurs employés de bureau chez eux. Pendant ce temps, la supply chain devait continuer de fonctionner, car les ouvriers dans les entrepôts et sur les trucks restaient actifs. Lokad fonctionnait déjà en grande partie à distance, permettant à nos Supply Chain Scientists de continuer à travailler depuis chez eux. Ce fut le véritable test de résistance : vérifier comment nos recettes s’exécuteraient sans supervision quotidienne. Dans certains cas, de grands clients comptaient littéralement des centaines de planificateurs, gestionnaires ou analystes qui, soudainement, n’étaient plus présents, mais leur supply chain devait tout de même fonctionner.
Et pour nous, cela a étonnamment bien fonctionné. Aucun de nos clients n’en a souffert — personne n’a disparu. Cela soulève la question : si vous pouvez gérer votre supply chain pendant 12 ou 14 mois sans 500 employés de bureau, en avez-vous vraiment besoin pour revenir ? C’était une expérience que nous n’aurions jamais pu réaliser autrement, car les entreprises ont généralement peur de faire entièrement confiance à un système automatisé. Mais les confinements les ont effectivement forcées à se reposer sur l’automatisation, prouvant que nous pouvions gérer d’immenses supply chains avec une intervention manuelle minimale, voire nulle. Bien sûr, nous continuons à discuter des moyens d’améliorer les recettes numériques ; il n’en va pas d’une collaboration nulle. Mais vous ne verrez plus de grandes équipes apporter quotidiennement des modifications Excel à chaque SKU dans chaque magasin.
Alors, si j’essaie d’imaginer où se dirige le monde de la supply chain : pour moi, cela ressemble à la transformation qui s’est produite dans la finance il y a 20 ans, lorsque le trading est devenu électronique. Les traders humains qui, autrefois, lisaient le journal du matin et décidaient manuellement d’acheter ou de vendre une action ont été remplacés par des quants disposant de vastes portefeuilles automatisés. Je vois la même transformation s’opérer dans la supply chain. Nous avons réalisé ce vieux rêve — mécaniser les décisions de supply chain. C’était l’ambition originelle de la recherche opérationnelle (l’“ancêtre” de la supply chain) dans les années 1940, 50 et 60. Au fil du temps, la recherche opérationnelle est devenue une sous-discipline à part entière, se concentrant sur les solveurs, mais si l’on regarde la vision initiale, c’est exactement ce que recherche la supply chain : les mathématiques, l’optimisation numérique, l’allocation des ressources. Nous avons atteint une version de cela chez Lokad il y a près de dix ans. Les confinements ont été notre véritable preuve que cela fonctionne à grande échelle, et ce, même pendant plus d’un an sans supervision directe.
De nos jours, nombre de nos clients laissent le système fonctionner entièrement de manière autonome. Par exemple, nous pouvons citer Cdiscount, un grand détaillant français du e-commerce : nous gérons pour eux les stocks des magasins de façon entièrement automatique, sans intervention manuelle. Cela n’empêche pas les discussions continues sur l’amélioration des recettes, mais l’approche quotidienne du “plus ou moins d’unités” a pris fin. Cela s’est terminé en 2020, et cela fonctionne toujours aujourd’hui.
En conséquence, je pense que nous sommes à la fin d’une ère, celle où environ cinq millions de personnes dans le monde doivent passer au crible un millier de SKUs par jour dans Excel pour décider s’ils doivent commander davantage, produire plus, réallouer des stocks, modifier les prix, etc. Toutes sortes d’intitulés de poste — gestionnaire des stocks, planificateur de la demande, planificateur de supply chain, responsable de catégorie, analyste S&OP — se résument à la même routine quotidienne : analyser une masse de SKUs. Avec de gros budgets, cela peut représenter 100 SKUs par personne ; avec des budgets plus modestes, peut-être 5 000 SKUs par personne. Quoi qu’il en soit, je crois que cette ère touche à sa fin.
Pourquoi maintenant ? Parce que pendant des décennies, personne n’a pu automatiser toutes ces décisions. Mais une fois qu’un certain nombre d’entreprises démontre que c’est possible, d’autres suivront. Il est extrêmement coûteux de maintenir de grandes équipes de planification manuelle, et il est difficile de pivoter stratégiquement lorsqu’il faut reconvertir des centaines de planificateurs répartis dans plusieurs pays, chacun habitué à la même routine quotidienne sur tableur depuis 20 ans. Changer cela se fait très lentement. Mais dès que vous pouvez passer à une approche purement programmatique, vous pouvez vous réorienter rapidement.
Voilà ce qui s’annonce : la même transformation que nous avons observée dans le secteur bancaire. Autrefois, des personnes négociaient manuellement toute la journée ; aujourd’hui, c’est en grande partie automatisé. Je vois la même mécanisation se profiler pour la supply chain, et je suis convaincu que cela deviendra une pratique standard bien avant votre départ à la retraite — que vous preniez votre retraite après 61 ans de travail, ou selon l’évolution des lois. Vous rencontrerez encore de nombreuses entreprises coincées dans des méthodes anciennes, mais cette révolution est en marche.
Mon message est donc le suivant : vous pouvez soit être un acteur actif de ce changement, soit n’être qu’un passager. Étant donné que vous êtes des étudiants de Central, vous avez probablement le potentiel pour être des moteurs du changement plutôt que de simples observateurs.
Bon, peut-être pouvons-nous passer aux questions. Je vous ai imposé un monologue de 50 minutes, alors si vous avez des questions à ce sujet, allez-y.
Étudiant: Oui, cela signifie-t-il que ces entreprises deviendront dépendantes de solutions comme Lokad, ou pourront-elles développer des technologies similaires en interne?
Joannes Vermorel: Les deux sont possibles. Si c’est une entreprise férue de technologie — comme un très grand acteur du e-commerce — parfois, ils envoient des équipes pour être formées par nous, dans l’idée d’internaliser le genre de pratiques utilisées par Lokad. Si une entreprise a une forte culture technologique et développe déjà beaucoup en interne, elle peut certainement le faire. Mais si sa culture est « Nous externalisons tout ce qui est trop compliqué », alors elle externalisera probablement. Dans l’ensemble, je pense que la plupart opteront pour des prestataires spécialisés, qu’il s’agisse de Lokad ou d’autres. Bien sûr, je suis partial — j’aimerais croire que Lokad figurera parmi ces solutions — mais quoi qu’il en soit, je suis convaincu que la révolution est en marche, d’une manière ou d’une autre.
Étudiant: Vous avez dit que les LLM ne remplaceraient pas les ingénieurs, seulement ceux qui n’utilisent pas les LLM. Quel facteur limite l’IA de sorte qu’elle ne puisse remplacer les ingénieurs qui utilisent les LLM? En d’autres termes, qu’est-ce qui empêche l’IA de surpasser les ingénieurs qui eux-mêmes utilisent l’IA?
Joannes Vermorel: Si je connaissais la réponse définitive, cela vaudrait mille milliards de dollars. Au fil des décennies, il y a eu de nombreuses avancées dans l’intelligence artificielle, chacune révélant une facette de ce qu’est l’intelligence — que nous n’avions pas entièrement comprise. Encore et encore, nous réalisons que nous nous étions trompés sur ce qui constitue une « véritable » intelligence.
Par exemple, si vous demandiez en 1940 ce qui témoignait d’une intelligence supérieure, on pourrait répondre : « Quelqu’un qui sait diagonaliser une matrice. » L’École Polytechnique avait même un département dédié à la diagonalisation des matrices, considéré comme le summum de la réussite intellectuelle. Aujourd’hui, un simple algorithme informatique peut diagonaliser une matrice ; nous ne considérons pas cela comme une intelligence du tout.
Nous avons connu une vingtaine de tels épisodes dans l’histoire de l’IA, découvrant à chaque fois que ce que nous pensions être de « l’intelligence » ne l’est pas. Les Large Language Models présentent actuellement des défauts flagrants — comme le fait de n’apprendre rien durant leur utilisation. Ce sont des modèles statiques. Vous pouvez leur fournir une invite, ils vous donnent une continuation, et c’est tout. Si vous utilisez à nouveau la même invite, vous obtenez la même continuation. Ils n’apprennent pas de la conversation. Vous pouvez effectuer un fine-tuning, oui, mais c’est un processus externe. Au quotidien, il n’y a ni mémoire ni amélioration persistante. Un humain qui fait un exercice apprend quelque chose ; un LLM n’apprend pas. Vous pouvez relancer le même scénario 200 fois, et il n’accumule pas de connaissances.
Un autre aspect étrange est la quantité massive de données requises par les LLM. Un enfant apprend à parler en environ trois ans, avec peut-être au maximum 1 000 heures d’écoute. Un LLM, apparemment, a besoin de lire l’internet entier — des milliards de tokens. Ou considérez les voitures autonomes : elles parcourent des millions de miles, virtuels ou réels, pour apprendre à faire ce qu’un humain maîtrise en 20 heures de leçons. Pourquoi autant de données pour de « l’intelligence »?
Nous sentons donc qu’il manque quelque chose de fondamental, mais nous ne savons pas précisément quoi. Peut-être que la prochaine itération des LLM ou une toute nouvelle approche résoudra ces insuffisances, mais nous ne savons pas si cela sera demain ou dans 20 ou 50 ans. Certains, comme Yann LeCun, disent que nous devrions abandonner entièrement l’approche des LLM et faire autre chose. Je n’en suis pas si sûr ; peut-être pouvons-nous ajuster les LLM pour remédier aux problèmes. Puisque personne n’a encore trouvé de solution, nous ne savons tout simplement pas.
Quoi qu’il en soit, ce sont là des limitations profondes qui empêchent un LLM de remplacer entièrement un humain, même dans des emplois relativement simples. Donc, oui, les LLM remplaceront les ingénieurs qui choisissent de ne pas les utiliser ; mais ils ne remplaceront pas forcément les ingénieurs qui les utilisent — ces personnes resteront indispensables.
Étudiant: Plus tôt, vous avez mentionné que Lokad restait rentable malgré un produit qui ne fonctionnait pas au début. Comment est-ce possible ? Avez-vous obtenu des financements ou des subventions ? Ou fournissiez-vous d’autres services ?
Joannes Vermorel: Non, aucune subvention ni financement extérieur. Laissez-moi vous expliquer : le marché de la supply chain est quelque peu fou. Les business plans typiques des concurrents depuis les années 1980 se déroulent ainsi : Étape 1, lever une somme considérable d’argent — des dizaines de millions. Étape 2, conquérir des parts de marché en se concentrant sur un segment vertical, comme l’aéronautique, pendant deux ou trois ans. Étape 3, embaucher 200 commerciaux, saisir 20 % du marché, puis finalement imploser. Et ainsi de suite.
Nous le voyons constamment. Même des géants comme Nike ont failli faire faillite en 2004 en raison d’un fiasco bien connu de logiciel de supply chain avec l’un de nos concurrents. La « catastrophe Nike » est documentée sur leur page Wikipedia. Ils ont essentiellement gâché neuf mois de production de Nike. Pendant ce temps, le même fournisseur a perturbé de nombreux clients, a été racheté, et l’acquéreur a fini par payer 250 millions de dollars de dommages et intérêts. D’après mon expérience, dans le logiciel d’entreprise, même si vous êtes moyen, on ne vous poursuit généralement pas en justice, donc ces gars devaient être vraiment affreux. Mais malgré ce bilan, ils ont simplement créé une nouvelle entreprise — les mêmes personnes — et levé un autre demi-milliard de dollars. Le marché n’apprend jamais.
Beaucoup de nos clients viennent en réalité vers nous après une demi-douzaine de tentatives désastreuses de projets de supply chain avec divers fournisseurs. L’automatisation de la supply chain est un vieux rêve ; les données sous-jacentes ont été numérisées depuis les années 80 ou 90, ils tentent donc depuis des décennies. Il est normal que les grandes entreprises accumulent une pile de projets ratés dans leur placard.
C’est l’environnement dans lequel nous évoluons. Il y a une énorme inertie. Les gens oublient. Le besoin demeure, alors ils réessaient encore et encore. Le marché peut sembler rationnel de loin, mais il met du temps à résoudre ces problèmes — surtout dans un domaine opaque comme le logiciel d’entreprise. Vous pouvez même avoir une mise en œuvre catastrophique, et pourtant le client pourrait tout de même vous offrir une étude de cas élogieuse, parce que le responsable qui a choisi votre produit ne veut pas être tenu pour compte. Ironiquement, un fiasco peut donc être présenté comme un succès dans le récit marketing. Voilà à quel point cela peut devenir désordonné.
Joannes Vermorel: D’autres questions ? Est-ce que tout ce que j’ai décrit vous semble normal, rationnel — ce à quoi vous vous attendiez du monde des affaires ?
Bien. Quoi qu’il en soit, je vous remercie tous énormément pour le temps passé à coder des scripts Envision. Je suis particulièrement fier de voir les étudiants de Central retrousser leurs manches et utiliser Envision. Je n’aurais jamais imaginé, lorsque j’ai écrit le premier compilateur il y a plus d’une décennie, qu’un jour je verrais des étudiants de Central travailler avec. C’était un pari risqué à l’époque ; il n’était pas question dans notre business plan de vous mettre en contact avec Envision, mais je suis ravi que cela soit arrivé. Et si Rémi ou Basil ne vous l’ont pas encore dit : Lokad recrute, juste pour que vous sachiez!
