00:00:00 L’histoire de la fondation de Lokad et ses premières années
00:02:31 Les idées reçues sur l’optimisation de la Supply Chain
00:04:31 Les théories de la Supply Chain existantes ne fonctionnaient pas
00:06:32 Le paradoxe des échecs de prévision
00:08:33 Comment « ne rien prévoir » a devancé la concurrence
00:10:25 Le défi de rejeter les idées établies
00:12:00 L’orientation vers la prévision probabiliste
00:14:07 L’importance des scénarios de demande extrêmes
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 le 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 Chain
00:42:49 Les LLMs 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 et 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 en gestion de la Supply Chain. Vermorel a raconté la création de Lokad après avoir obtenu son diplôme de l’École Normale Supérieure et avoir déplacé son intérêt 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 question 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 de la Supply Chain. 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
Lors d’une conférence donnée aux étudiants en français, Joannes Vermorel, CEO et fondateur de Lokad, a partagé son parcours et ses perspectives sur l’univers de la gestion de la Supply Chain et l’évolution de son entreprise. Vermorel a commencé par se présenter et a raconté les origines de Lokad, une entreprise qu’il a fondée dès sa sortie 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 relaté le développement d’Envision, précisant que le premier compilateur qu’il avait écrit a rapidement été remplacé par une version supérieure réalisée par Victor Nicolet, le CTO de Lokad. Depuis, Envision a considérablement évolué, et l’entreprise est désormais sur le point de lancer la version 6.
Le parcours de Lokad a débuté 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 intervenue après avoir épuisé toutes les autres alternatives. Au départ, il croyait 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 pensait que la clé du succès résidait dans la réemballage des théories existantes de la Supply Chain sous forme d’applications web, tirant parti 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 relaté une expérience particulièrement absurde en 2011, où Lokad a remporté un benchmark en soumettant des prévisions nulles, surpassant ainsi la concurrence avec une précision supérieure de 20%. Cette expérience a amené Vermorel à remettre en question la validité des théories traditionnelles de la Supply Chain, les comparant à l’astrologie plutôt qu’à l’astronomie.
Vermorel a souligné l’importance de remettre en question le consensus en science, notant que l’histoire regorge d’exemples de croyances largement acceptées mais finalement incorrectes. Il en a conclu que, bien que la Supply Chain en soi soit un domaine légitime, les théories classiques qui la sous-tendent étaient défectueuses. Cette prise de conscience l’a poussé à explorer des approches alternatives, telles que les prévisions biaisées et les prédictions par quantiles, qui se sont avérées plus efficaces.
L’approche de Lokad a évolué pour adopter des méthodes probabilistes et programmatiques, s’éloignant ainsi des modèles traditionnels qui ne parvenaient pas à répondre aux complexités des problèmes réels de la Supply Chain. Vermorel a souligné l’importance de disposer d’un langage de programmation robuste, adapté à ces défis, critiquant l’utilisation de langages polyvalents comme Python, qui entraînaient 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 Chain. Vermorel a noté que les solutions de Lokad se sont avérées efficaces à grande échelle, gérant des stocks valant des milliards d’euros avec une intervention humaine minimale. Ce changement reflète la transition dans le secteur financier, où le trading est devenu majoritairement algorithmique.
Vermorel a abordé l’avenir de la gestion de la Supply Chain, prédisant que les rôles traditionnels des responsables des stocks et des planificateurs de demande 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 l’impulsion de cette révolution plutôt que de se contenter de l’observer.
En réponse aux questions des étudiants, Vermorel a expliqué que les entreprises à forte orientation technologique pourraient internaliser les solutions de Lokad, tandis que d’autres continueraient probablement à externaliser ces services. Il a également évoqué les limites des grands modèles de langage (LLMs) comme ChatGPT, soulignant leur absence de capacités d’apprentissage et de mémoire.
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é des fonds considérables à plusieurs reprises, 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 des étudiants d’institutions prestigieuses comme Centrale. Il a invité les étudiants à envisager de rejoindre Lokad, soulignant les efforts continus 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 la fin de mes études. J’étais à l’École Normale Supérieure, j’avais commencé un doctorat en bioinformatique, mais finalement, tant de personnes faisaient déjà 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 pour moi que de me retrouver devant des étudiants de Centrale pour parler de ce langage. Ce n’est pas quelque chose que j’aurais pu imaginer il y a douze ans, quand j’ai créé Envision.
J’ai écrit le premier compilateur d’Envision, puis Victor Nicolet—le CTO de Lokad—l’a jeté et a rapidement écrit le second compilateur, qui était bien meilleur. Et maintenant, vous utilisez essentiellement la version 5, tandis que la version 6 est sur le point d’être lancée. Le langage a beaucoup évolué. Mais ce sur quoi vous avez travaillé—la portion que vous avez vue—n’était pas du tout le point de départ de Lokad. Cela est intervenu assez tard. 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—c’est simplement que tout le reste avait échoué.
Pour vous donner une idée de ce qui surprend tant 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 ouvrages ont été publiés, mais ces 10 000-là sont ceux qui sont encore en vente. C’est un domaine extrêmement documenté.
Quand j’ai commencé, j’ai vu de gros concurrents aux noms prestigieux : SAP, Oracle, IBM, voire Microsoft—des acteurs majeurs de 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—totalement erronée, il s’avère—était que je pouvais prendre les théories établies de la Supply Chain et les reconditionner en une application web. C’était en 2008, et tous les logiciels d’entreprise passaient des applications dites « thick client », installées sur votre PC, aux applications « thin client », c’est-à-dire web. Il y avait donc l’opportunité de reconstruire des logiciels de Supply Chain sous forme d’application web, possiblement avec de l’hébergement en cloud computing. Lokad est passé au cloud très tôt. Cela pourrait nous donner un avantage sur les grandes entreprises encore fidèles aux systèmes client lourds et anciens. Et comme il existe littéralement des ouvrages entiers expliquant comment optimiser les Supply Chain—comme le manuel du MIT, le manuel de Stanford, le manuel de Caltech—je les ai tous lus, ces volumes de 1 000 pages écrits par deux ou trois professeurs avec toutes les équations.
J’ai ensuite programmé ces approches—et rien ne fonctionnait. Fait intéressant, cela n’a pas empêché Lokad de se développer 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 domaine des logiciels d’entreprise, on peut vendre quelque chose qui ne fonctionne pas du tout, tout en trouvant des clients. Cela peut paraître étrange, mais c’est ainsi. En réalité, s’il y a un gros problème que l’entreprise cherche à résoudre, il existe un budget pour tenter 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, tirant parti de cette asymétrie, j’ai commencé et tenté de mettre en œuvre ces théories classiques de la Supply Chain : la prévision des séries temporelles et le stock de sécurité, l’optimisation du taux de service, etc. Rien n’y fonctionnait, absolument rien. Nous avons eu des discussions plutôt schizophréniques avec les clients : ils disaient, « Vous avez dû coder la formule du stock de sécurité de manière incorrecte », alors nous revenions, prenions littéralement les valeurs des tableaux des manuels, revérifiions les paramètres — et c’était exactement comme indiqué. La théorie avait été mise en œuvre 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é 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, avec 5 000 SKUs par supermarché, nécessitant des prévisions sur quelques jours, car ces supermarchés étaient 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 de chaque produit pour chaque magasin — essentiellement l’erreur absolue entre la prévision et le réel. Lokad a finalement remporté ce benchmark — en affichant une précision de prévision supérieure de 20 %, écrasant totalement 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 vitesse de calcul, car renvoyer des zéros est extrêmement rapide. Et si vous prévoyez une demande nulle, vous n’approvisionnez pas le magasin, si bien qu’en deux semaines, le magasin est vide, correspondant à votre prévision à 100%. J’étais le roi des statistiques.
Évidemment, c’était un complet non-sens. Mais si vous considérez l’approche recommandée par tous les manuels de la Supply Chain et le processus standard des clients, cela a abouti à 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 j’avais peut-être découvert par hasard un système. On peut démarrer quelque chose, cela rapporte de l’argent, mais c’est du pur non-sens. Peut-être qu’au début, on est simplement trop inexpérimenté pour s’en apercevoir. Mais une fois que vous réalisez que ce que vous faites est absurde, continuez-vous ? Lorsque vous obtenez votre diplôme et découvrez que ce que vous faites est absurde, continuez-vous ? Cela a déclenché un questionnement profond. La Supply Chain ne pourrait-elle être qu’une forme d’astrologie — du genre divinatoire, pas astronomique ?
Finalement, j’en suis arrivé à conclure que la Supply Chain en tant que domaine est réelle, mais que la théorie standard de la Supply Chain n’est essentiellement que de l’astrologie. C’était la faille. 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 requise. Si vous consultez quatre médecins différents, chacun vous affirmant 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 s’accorder sur quelque chose et avoir tort. L’histoire des sciences est pleine d’exemples : un consensus extrêmement large sur des idées qui se sont avérées folles. Certains, qui étudient l’histoire des sciences, disent même que la moitié de ce qu’une société croit à un moment donné est erronée ; la partie délicate réside dans le fait de savoir quelle moitié.
Donc, Lokad a tiré cette conclusion du benchmark : la méthode traditionnelle était absurde. Nous devions chercher autre chose. Notre grand tournant est survenu début 2012, en nous attaquant aux prévisions biaisées avec ce qu’on appelle les prévisions quantiles. À l’époque, j’avais des clients employant 50 personnes à temps plein rien que pour éliminer le biais. Ils m’ont donc 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 ne pourraient jamais l’enlever manuellement. Mais si j’appelle cela “quantile forecasting,” ça sonne plus scientifique que “biased forecasting.” En réalité, cependant, une prévision quantile n’est qu’une prévision biaisée.
Nous avons essayé 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é représentait un grand progrès.
Cela nous a ensuite conduits à revoir toutes les hypothèses de la supply chain présentes dans les manuels — remettant en cause chaque fondement, qui s’est avéré très fragile, en gros erroné. La prévision quantile n’est qu’une version simplifiée de cela. C’est un outil statistique qui s’intéresse spécifiquement aux extrêmes. Économiquement, dans la supply chain, ce sont les extrêmes qui font perdre de l’argent : une demande exceptionnellement élevée qui crée une rupture de stock, une demande exceptionnellement faible qui génère un surstock, des délais d’approvisionnement anormalement longs qui ruinent vos plans, etc. Ce n’est jamais le milieu de la distribution qui vous nuit réellement ; ce sont les queues. Une prévision quantile est un outil qui se concentre sur ces extrêmes. Une version améliorée est la prévision probabiliste — ce sur quoi vous avez travaillé — où l’on obtient une distribution de probabilité complète. En 2012, nous avons commencé avec les prévisions quantiles car 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 seul chiffre de prévision 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 répondre à cette 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 de logiciels : à mesure que l’on ajoutait des fonctionnalités, le mappage des données depuis 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 contenir 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 ERPs, 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 la “date de commande” peut avoir 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 le secteur de l’habillement, par exemple, une entreprise pourrait définir les variantes uniquement par la couleur et la taille, tandis qu’une autre pourrait également inclure la composition du tissu. Ou, dans l’alimentation, vous pourriez avoir une “date d’expiration” signifiant le jour où le produit ne peut absolument plus être vendu, ou 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. Nous avions besoin de quelque chose de nouveau : une approche programmatique. C’est un aspect que les manuels de supply chain n’abordent jamais. Les modèles standard ne sont pas utiles parce que le monde réel ne correspond jamais parfaitement à ces modèles. Il y a toujours quelque chose — quantité minimale de commande, contraintes d’expiration, contraintes de planning des expéditions. Les contraintes propres à chaque entreprise sont uniques. Nous avons donc compris que la solution devait être programmatique et non une formule statique. La question devenait alors : quel est le bon paradigme de programmation pour la supply chain ?
En 2012, certains pouvaient dire, “Why not just use Python?” En effet, à l’époque, c’est exactement ce que faisaient tous mes clients américains du e-commerce. Presque toutes les initiatives de data science que j’observais é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. Puis, ils voulaient le mettre en production, et un an plus tard, ce n’était toujours pas déployé ; la direction perdait patience, annulait le projet, et c’était fini.
Pourquoi cela a-t-il échoué ? Une mort par mille coupures : NullReferenceException, OutOfQuotaException, problèmes de concurrence, packages incompatibles, failles de sécurité, rançongiciels dans votre environnement, etc. Rien de tout cela n’est directement lié au problème de la 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, la surface d’attaque pour les problèmes est énorme. Par exemple, si votre code peut écrire sur le système de fichiers, vous pouvez accidentellement corrompre l’environnement qui l’héberge — chose facile à faire si 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, etc. Ces situations surviennent inévitablement au milieu de la nuit, sans qu’il y ait quelqu’un pour intervenir 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 s’est effondré à minuit.
Dans les démonstrations de data science, il y a généralement un gardien qui lance le script, si bien qu’en cas de plantage, il le répare. Mais l’automatisation de la supply chain dans le monde réel doit fonctionner sans supervision quotidienne. 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 à cause de la grande complexité des langages à usage général, et non de la logique de la supply chain elle-même.
Tout cela a conduit Lokad à réaliser que nous avions besoin d’un environnement programmatique suffisamment sûr et spécialisé pour gérer des opérations quotidiennes à grande échelle sans surveillance fragile. De plus, une fois que nous avons reconnu la nécessité de réaliser des prévisions avancées (probabilistes, quantiles, etc.), Envision a été configuré pour gérer ces flux de travail en tant que fonctionnalités de première classe. Par exemple, si vous souhaitez de la programmation différentiable pour le machine learning, dans un langage à usage général vous intégrez un autre “mini-langage” comme PyTorch pour ce faire. Ensuite, vous avez Python plus un morceau de code PyTorch, et il est facile de commettre des erreurs, car votre code PyTorch est essentiellement une chaîne non compilée. Il en va de même pour l’intégration de requêtes SQL dans votre code Python. Tout est du texte, si bien que vous ne découvrez vos fautes de frappe qu’à l’exécution. Envision, en revanche, peut traiter ces fonctionnalités comme des caractéristiques intégrées avec des vérifications de compilation.
L’approche de Lokad a évolué parallèlement à des avancées telles que le deep learning — où vous n’avez plus simplement une bibliothèque de modèles préconçus, mais vous composez vous-même votre modèle de manière programmatique. TensorFlow est essentiellement un langage pour construire des graphes computationnels. Vous n’êtes pas limité à un “catalogue” 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 ? Il s’agit de 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 la supply chain. Vous avez vu des versions plus simples avec des contraintes minimales, mais les entreprises réelles font face à une multitude de contraintes : des minimums de commande, des taux de couverture pour les conteneurs, des contraintes de catégorie ou des calendriers compliqués. De plus, votre fonction coût/bénéfice est incertaine. Ce sont donc des concepts programmatiques avancés.
En somme, Envision n’a cessé d’ajouter des fonctionnalités. À ce jour, nous sommes également sur le seuil 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, alors vous pouvez l’admettre !) Ou même payer pour la version pro. Ce qui est intéressant pour nous, c’est que Lokad possède 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 le “quoi” de 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 — parfois elles le sont, au début — ces changements sont intégrés dans un workflow afin que nous puissions 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, de sorte que nous pouvons également en tirer des enseignements.
Ensuite, nous avons un second artefact textuel, le JPM ou Joint Process Manual, qui explique le “pourquoi.” C’est notre document de référence pour les transmissions et pour offrir 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.”
Ça correspond assez bien aux LLMs, car ils traitent le texte. Ils ne sont pas très performants avec des 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 générer qu’un morceau de code Python qui réaliserait la régression. Les LLMs eux-mêmes ne sont que d’immenses modèles de prédiction de token suivant ; ils ne sont pas conçus pour l’arithmétique. D’où les blagues sur ChatGPT qui échoue 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.
Ainsi, voilà où se positionne Lokad : nous disposons d’automatisations avancées de la supply chain pouvant fonctionner pendant des mois sans intervention humaine — ce qui a été démontré pendant les confinements de 2020–2021, lorsque bon nombre de nos clients ont envoyé leurs employés de cols blancs chez eux. Pendant ce temps, la supply chain devait continuer de fonctionner parce que la main-d’œuvre de cols bleus dans les entrepôts et les trucks était toujours active. Lokad fonctionnait déjà en grande partie à distance, ainsi nos Supply Chain Scientists pouvaient continuer à travailler de chez eux. Ce fut le véritable test de résistance : voir comment nos recettes s’exécutaient sans supervision quotidienne. Dans certains cas, de grands clients comptaient littéralement des centaines de planificateurs, de managers ou d’analystes qui n’étaient soudain plus présents, mais leur supply chain devait quand même fonctionner.
Et pour nous, cela a fonctionné de manière étonnamment satisfaisante. Aucun de nos clients n’en a souffert — personne n’a disparu. Cela soulève la question : si vous pouvez faire fonctionner votre supply chain pendant 12 ou 14 mois sans 500 employés de cols blancs, en aurez-vous vraiment besoin par la suite ? C’était une expérience que nous n’aurions jamais pu réaliser autrement, car les entreprises ont généralement peur de confier entièrement leur système à l’automatisation. Mais les confinements les ont effectivement forcées à compter sur l’automatisation, prouvant que nous pouvions faire fonctionner 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 ; ce n’est pas une collaboration nulle. Mais on ne voit plus de grandes équipes effectuer quotidiennement des modifications Excel sur chaque SKU dans chaque magasin.
Donc, si j’essaie de voir où se dirige le monde de la supply chain : pour moi, cela ressemble au changement survenu dans la finance il y a 20 ans, lorsque le trading est passé à l’é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 constate la même transformation dans la supply chain. Nous avons réalisé ce vieux rêve — mécaniser les décisions de la 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 sa propre sous-discipline, 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 presque dix ans. Les confinements ont été notre véritable preuve que cela fonctionne à grande échelle, même pendant plus d’un an sans supervision directe.
Nombre de nos clients laissent aujourd’hui le système fonctionner entièrement de lui-même. Par exemple, nous pouvons citer Cdiscount, un grand détaillant français du e-commerce : nous gérons leurs stocks de magasin de manière entièrement automatique, sans intervention manuelle. Cela n’empêche pas les discussions en cours sur la manière d’améliorer les recettes, mais l’approche quotidienne du “plus ou moins d’unités” est révolue. Cela a pris fin en 2020, et cela fonctionne encore aujourd’hui.
Par conséquent, je pense que nous sommes à la fin d’une ère, celle où environ cinq millions de personnes dans le monde ont pour mission de passer au crible un millier de SKUs par jour dans Excel pour décider s’il faut commander plus, fabriquer davantage, déplacer les stocks, modifier les prix, etc. Toutes sortes de titres — gestionnaire de stocks, demand planner, supply planner, category manager, analyste S&OP — se résument à la même routine quotidienne : parcourir un ensemble 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 époque 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émontrent que c’est faisable, d’autres suivront. Il est extrêmement coûteux de maintenir de grandes équipes de planification manuelle, de plus il est difficile de pivoter stratégiquement lorsqu’il s’agit de former à nouveau des centaines de planificateurs répartis dans plusieurs pays, chacun habitué à suivre la même routine quotidienne sur tableur pendant 20 ans. Changer cela est très lent. Mais une fois que vous pouvez opérer purement de manière programmatique, vous pouvez rediriger rapidement.
C’est ce qui s’annonce : le même bouleversement que nous avons observé dans le secteur bancaire. Autrefois, des personnes effectuaient des transactions 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 crois que cela deviendra une pratique standard bien avant que vous ne preniez votre retraite — que vous preniez votre retraite après 61 ans de travail, ou quelle que soit l’évolution des lois. Vous rencontrerez encore de nombreuses entreprises coincées dans des méthodes obsolètes, mais cette révolution est en marche.
Donc, mon message est le suivant : vous pouvez soit être un moteur actif de ce changement, soit rester simplement passager. Étant donné que vous êtes des étudiants de Central, vous avez probablement le potentiel pour être des acteurs du changement plutôt que de simples observateurs.
Bien, peut-être pouvons-nous passer aux questions. Je vous ai imposé un monologue de 50 minutes, donc si vous avez des questions à propos de tout cela, allez-y.
Étudiant: Oui, cela signifie-t-il que ces entreprises deviendront dépendantes de solutions comme Lokad, ou peuvent-elles développer des technologies similaires en interne ?
Joannes Vermorel: Les deux sont possibles. S’il s’agit d’une entreprise technophile—comme un très grand acteur du e-commerce—parfois, ils envoient des équipes se faire former par nos soins, avec l’idée d’internaliser le type de pratiques que Lokad emploie. Si une entreprise a une forte culture technologique et développe déjà beaucoup en interne, elle peut certainement le faire. Mais si leur culture est « Nous externalisons tout ce qui est trop compliqué », alors ils externaliseront probablement. Dans l’ensemble, je pense que la plupart opteront pour des fournisseurs spécialisés, qu’il s’agisse de Lokad ou d’autres. Bien sûr, je suis partial—j’aimerais croire que Lokad fera partie de ces solutions—mais en tout cas, 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 pas remplacer ces ingénieurs qui utilisent les LLM ? En d’autres termes, qu’est-ce qui empêche l’IA de surpasser les ingénieurs qui utilisent eux-mêmes l’IA ?
Joannes Vermorel: Si je connaissais la réponse définitive, elle vaudrait mille milliards de dollars. Au fil des décennies, il y a eu de nombreuses percées en intelligence artificielle, révélant à chaque fois une facette de ce qu’est l’intelligence — que nous n’avions pas complètement comprise. À maintes reprises, nous réalisons que nous nous étions trompés sur ce qui constitue une « vraie » intelligence.
Par exemple, si vous aviez demandé en 1940 ce qui démontre une intelligence supérieure, on aurait pu 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 l’accomplissement intellectuel. Aujourd’hui, un simple algorithme informatique peut diagonaliser une matrice ; nous ne considérons pas cela comme de l’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 celui de n’apprendre réellement rien lors de leur utilisation. Ce sont des modèles statiques. Vous pouvez leur donner une invite, ils vous fournissent une continuation, et c’est tout. Si vous répétez 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 réexécuter 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 1 000 heures d’écoute au maximum. Un LLM a apparemment besoin de lire l’internet entier — des milliards de tokens. Ou encore, pensez aux 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 cours. 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 approche complètement nouvelle corrigera ces lacunes, mais nous ne savons pas si cela arrivera demain ou dans 20 ou 50 ans. Certains, comme Yann LeCun, disent que nous devrions abandonner complètement 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 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 nécessairement les ingénieurs qui les utilisent — ces personnes resteront indispensables.
Étudiant: Plus tôt, vous avez mentionné que Lokad est resté rentable même si le produit ne fonctionnait pas au début. Comment est-ce possible ? Avez-vous obtenu des financements ou des subventions ? Ou proposiez-vous d’autres services ?
Joannes Vermorel: Non, pas de subventions ni de financements externes. Laissez-moi vous expliquer : le marché de la supply chain est un peu fou. Les plans d’affaires typiques des concurrents depuis les années 1980 se ressemblent : Étape 1, lever une montagne d’argent — des dizaines de millions. Étape 2, conquérir des parts de marché en se concentrant sur un secteur spécifique, comme l’aéronautique, pendant deux ou trois ans. Étape 3, embaucher 200 commerciaux, s’emparer de 20 % du marché, puis finalement imploser. Répétez l’opération.
Nous voyons cela constamment. Même des géants comme Nike ont failli faire faillite en 2004 à cause d’un fiasco bien connu des logiciels 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 chez Nike. Pendant ce temps, le même fournisseur a fait échouer de nombreux clients, a été racheté, et l’acquéreur a fini par payer 250 millions de dollars de dommages. D’après mon expérience, dans le secteur des logiciels d’entreprise, même si vous êtes médiocre, vous ne vous faites généralement pas poursuivre en justice, donc ces types devaient être vraiment affreux. Mais malgré ce dossier, ils ont simplement lancé une nouvelle entreprise — les mêmes personnes — et ont levé un autre demi-milliard de dollars. Le marché n’apprend jamais.
Nombre de nos clients viennent en réalité à nous après une demi-douzaine de tentatives désastreuses de projets de supply chain avec différents 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 essaient donc cela depuis des décennies. Il est normal que les grandes entreprises aient 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 persiste, donc ils réessaient encore et encore. Le marché peut sembler rationnel de loin, mais il est lent à résoudre ces problèmes — surtout dans un domaine opaque comme les logiciels d’entreprise. Vous pouvez même avoir une mise en œuvre catastrophique, et pourtant le client pourrait vous offrir une étude de cas élogieuse, car le responsable qui a choisi votre produit ne veut pas être blâmé. Ainsi, ironiquement, un fiasco peut être présenté comme un succès dans le discours marketing. Voilà jusqu’où cela peut devenir désordonné.
Joannes Vermorel: D’autres questions ? Tout ce que j’ai décrit vous semble-t-il normal, rationnel — ce à quoi vous vous attendiez dans le monde des affaires ?
Très bien. Quoi qu’il en soit, je vous remercie tous énormément pour le temps que vous avez passé à coder des scripts Envision. Je suis très 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, que je verrais un jour des étudiants de Central travailler avec. C’était un pari risqué à l’époque ; il n’était pas prévu dans notre plan d’affaires de vous mettre en avant avec Envision, mais je suis ravi que cela se soit produit. Et si Rémi ou Basil ne vous l’ont pas encore dit : Lokad recrute, juste pour que vous le sachiez!
