00:00:00 Introduction à l’interview
00:01:01 L’impact de l’IA sur les emplois traditionnels
00:04:36 Automatisation de l’IA dans la supply chain
00:09:08 Besoin d’un système unifié en 2012
00:10:30 Réinjecter des décisions dans les systèmes
00:13:08 Éviter le problème des hallucinations dans l’IA
00:16:11 Impact et retards dus au backlog informatique
00:20:04 Comparaison des configurations de Lokad et d’autres fournisseurs
00:23:06 Discussion sur les hallucinations et confabulations des LLM
00:30:38 Mettre l’accent sur le progrès plutôt que sur la perfection en IA
00:33:00 Récupération des informations manquantes et l’ETA des commandes
00:36:17 Tâches quantitatives et LLM dans la supply chain
00:38:28 L’avenir des AI Pilots dans la supply chain
00:41:18 La valeur des conversations et l’automatisation des tâches à faible valeur ajoutée
00:44:57 Exploiter les AI Pilots pour réduire le backlog
00:49:00 AI Pilot vs copilot et scénario de confinement
00:53:36 Scepticisme envers l’IA conversationnelle et analyse des processus
00:57:18 Comprendre la réalité des affaires et le remplacement des processus par l’IA
01:00:12 Les défis de l’open source d’Envision
01:06:21 L’approche de l’IA face aux goulets d’étranglement dans la supply chain
01:09:17 L’inefficacité des commandes verbales et l’automatisation des commandes
01:14:12 Supply Chain Scientist comme copilote pour AI Pilot
01:17:32 Vérifier la justesse des données et automatiser les contrôles avec les LLM
01:20:15 Rendre Envision convivial avec Git
01:21:14 Ressources gratuites pour apprendre Envision
Résumé
Dans un dialogue entre le CEO de Lokad, Joannes Vermorel, et le Responsable Communication Conor Doherty, ils discutent de l’impact de l’IA sur la gestion de la supply chain. Vermorel met en lumière les avancées de l’IA et des large language models, qui ont révolutionné l’automatisation des tâches. Il présente AI Pilots, une offre de Lokad qui automatise la prise de décisions et les tâches administratives, facilitées par le langage de programmation propriétaire de Lokad, Envision. Vermorel aborde également le potentiel de l’IA à automatiser les tâches liées aux master data et compare l’approche de Lokad à celle de ses concurrents. Il prédit que AI Pilots deviendra la norme dans la gestion de la supply chain, entraînant d’importantes améliorations de productivité. La conversation se termine par une session de questions-réponses.
Résumé Étendu
Dans une conversation récente entre Conor Doherty, Responsable Communication chez Lokad, et Joannes Vermorel, CEO et fondateur de Lokad, le duo s’est penché sur le rôle transformateur de l’intelligence artificielle (IA) dans la gestion de la supply chain. La discussion, qui prolongeait une conversation précédente sur l’impact de l’IA sur l’emploi, s’est concentrée sur le potentiel de l’IA à agir en tant que pilote autonome pour la prise de décisions dans la supply chain.
Vermorel a commencé par souligner l’accomplissement phare de l’IA générative et des large language models (LLMs) en 2023. Ces avancées, explique-t-il, ont révolutionné l’automatisation des tâches impliquant le texte, telles que la lecture des emails ou la catégorisation des plaintes. L’année 2023 a été particulièrement marquante car elle a vu une réduction substantielle du coût opérationnel des techniques de traitement du langage naturel pour les entreprises. Vermorel a prédit que cela conduirait à l’automatisation de nombreuses fonctions de support interne, les opérations de la supply chain étant en première ligne.
Vermorel a ensuite présenté AI Pilots, une offre de Lokad qui automatise le processus de prise de décisions et gère les tâches administratives banales. Il a souligné l’approche unique de Lokad, où un Supply Chain Scientist peut prendre l’entière responsabilité d’une initiative. Cela est facilité par le langage de programmation propriétaire de Lokad, Envision, dédié à l’optimisation prédictive des supply chains. Cependant, Vermorel a admis que Lokad avait auparavant rencontré des difficultés dans la recherche de données et la gestion de divers dialectes SQL.
Selon Vermorel, l’introduction de GPT-4 a bouleversé le jeu pour Lokad, permettant à l’entreprise d’automatiser la composition de requêtes SQL. Ces requêtes peuvent ensuite être relues par un Supply Chain Scientist et testées pour garantir leur précision. Ce développement, associé à une connexion cloud-to-cloud sécurisée, permet à l’équipe de Supply Chain Scientists de Lokad de récupérer les données des clients de manière autonome, réduisant ainsi les délais.
Vermorel a également souligné le potentiel des LLM à automatiser de nombreuses tâches liées aux master data, y compris la collecte d’informations, la surveillance et l’amélioration. Il a comparé l’approche de Lokad à celle de ses concurrents, affirmant que Lokad fait généralement intervenir moins de personnes dans une initiative, chaque personne ayant des compétences sur l’ensemble du processus. Cela, selon lui, contraste fortement avec les concurrents qui impliquent souvent beaucoup plus de personnes, notamment des chefs de projet, des consultants, des designers UX, des administrateurs de bases de données, des spécialistes des réseaux et des programmeurs.
La conversation s’est ensuite tournée vers le rôle des Supply Chain Scientists dans la validation ou la surveillance des scripts générés par les LLM. Vermorel a reconnu que les LLM peuvent parfois produire des résultats inexacts ou « hallucinés », mais ceux-ci sont généralement corrects dans leur orientation et peuvent être corrigés après quelques itérations via une boucle de rétroaction. Il a suggéré que, bien que les LLM puissent faire des erreurs, ils apportent tout de même une grande valeur, et que leur taux de faux positifs et de faux négatifs peut être mesuré.
Vermorel a en outre expliqué l’orchestration quotidienne entre le Supply Chain Scientist, l’AI Pilot et le client. L’AI Pilot, composé par le Supply Chain Scientist, gère les opérations quotidiennes de la supply chain, prenant en charge les détails de la préparation des données et les décisions relatives aux bons de commande. Le client, dans ce dispositif, est assimilé au capitaine, donnant des orientations stratégiques globales.
En termes de points clés pour les praticiens de la supply chain et les équipes dirigeantes, Vermorel a prédit que, dans une décennie, les AI Pilots deviendront la norme dans la gestion de la supply chain (SCM). Selon lui, cela conduira à une amélioration massive de la productivité, avec une réduction potentielle de 90 % des effectifs pour les fonctions précédentes. Il a encouragé les praticiens de la supply chain à consacrer davantage de temps à la réflexion stratégique et à des conversations approfondies avec les fournisseurs et les clients.
La conversation s’est conclue par une session de questions-réponses, au cours de laquelle Vermorel a répondu à diverses questions, notamment sur le rôle des AI Pilots dans la réduction du backlog informatique, la différence entre un AI Pilot et un copilot, l’importance de l’analyse des processus avant la mise en œuvre d’un modèle d’IA, les projets de Lokad visant à open sourcer Envision, et la manière dont l’IA aborde les goulets d’étranglement aléatoires. Il a également confirmé que Lokad travaille sur un copilot Lokad et prévoit de rendre Envision plus compatible avec GitHub.
Transcription Complète
Conor Doherty: Bienvenue sur Lokad live. Je m’appelle Conor. Je suis le Responsable Communication ici chez Lokad. Et je suis rejoint en studio par le fondateur de Lokad, Joannes Vermorel.
Le sujet d’aujourd’hui porte sur la manière dont l’IA peut agir en tant que pilote autonome pour la prise de décisions dans la supply chain. N’hésitez pas à soumettre vos questions à tout moment dans le chat YouTube, et nous y répondrons dans environ 30 à 35 minutes.
Et sur ce, Joannes, il me semble que les AI Pilots dans la supply chain font de cette conversation une véritable prolongation de celle que nous avons eue, je crois il y a environ quatre semaines, où nous avons parlé des implications de l’IA sur l’emploi et de l’avenir des emplois traditionnels face à l’IA dans la supply chain.
Avant d’entrer dans les détails des AI Pilots, pourriez-vous, pour ceux qui n’ont pas vu cela, nous rappeler, en quelques points, quelle est notre vision des emplois traditionnels par rapport à l’IA dans la supply chain ?
Joannes Vermorel: Pour résumer, un jalon a été franchi en 2023. Ce jalon est l’IA générative et, plus précisément, les large language models (LLMs). En termes de recherche pure, il s’agit simplement d’une continuité d’environ quatre à cinq décennies d’améliorations continues en apprentissage automatique. Donc, si l’on considère cela du point de vue de la recherche, 2023 n’est qu’une année parmi d’autres dans une longue série de progrès. Et les deux dernières décennies ont connu des progrès relativement rapides.
En 2023, ce qui arrive sur le marché, c’est de l’IA générative emballée pour l’image et, plus important encore, pour le texte. Et un produit a popularisé cela, c’est ChatGPT d’OpenAI. Qu’est-ce que cela signifie ? Cela signifie très précisément, en particulier ces large language models, que vous disposez d’une machine de modélisation universelle résiliente au bruit.
Cela signifie que toutes les étapes pour les logiciels d’entreprise, je parle ici dans le contexte des employés de bureau dans des environnements corporatifs, c’est-à-dire que toutes les étapes qui ne pouvaient pas être automatisées par le passé parce que nous devions traiter le texte sous une forme ou une autre, comme lire un email, extraire une référence ou un prix d’un email, ou une quantité, ou catégoriser le type de réclamation ou de demande d’un partenaire, d’un fournisseur ou d’un client à partir d’un email, identifier si l’étiquette d’un produit est incohérente, par exemple, si l’étiquette du produit indique littéralement que la description du produit est manquante, bon, nous avons un problème, toutes ces choses, par le passé, ne pouvaient pas être faites facilement. Elles pouvaient être réalisées d’une autre façon, mais elles ne pouvaient pas être automatisées aisément.
Si nous devions remonter, disons, cinq ans en arrière, le text mining existait déjà. Il était déjà possible d’avoir des classificateurs de texte et d’utiliser toutes sortes de techniques de traitement du langage naturel, mais elles étaient coûteuses. 2023 fut une année charnière car tous ces problèmes, dus au degré de packaging atteint essentiellement avec GPT-4 fourni via une API, ont permis de réduire les coûts opérationnels de ces techniques NLP, techniques de traitement du langage naturel, pour les entreprises, par un facteur de 100, voire 1 000. Ce qui signifie que non seulement le coût, mais aussi le délai nécessaire pour mettre en place tout cela a été considérablement réduit.
En résumé, et c’est ma prédiction, de nombreuses fonctions de support au sein des entreprises, qui ne sont que des fonctions internes, prenant des données en entrée pour produire un résultat pour d’autres divisions, seront automatisées. La supply chain est en première ligne car ce n’est pas exactement une fonction en contact direct avec la clientèle. C’est une fonction essentiellement interne, importante certes, mais interne. Ainsi, les large language models se sont révélés être la pièce manquante pour automatiser de bout en bout la grande majorité des opérations banales dans les supply chains.
Lokad automatise l’analyse quantitative et le processus de prise de décisions quantitatives depuis une décennie, mais il existe de nombreuses opérations banales qui précèdent et qui suivent, et ce sont celles qui peuvent être automatisées grâce aux large language models, de manière rapide et économique.
Conor Doherty: Eh bien, merci. Et nous avons déjà une vidéo dans laquelle nous avons parlé, je pense, pendant environ une heure et demie sur ce sujet, donc je ne vais pas y consacrer plus de temps aujourd’hui, mais cela ouvre la voie au reste de la conversation. J’invite cordialement quiconque souhaite en savoir plus sur ce sujet à consulter la vidéo précédente. Sur ce, les AI Pilots, comment s’intègrent-ils dans tout ce que vous venez de dire ? Que sont-ils ? Que font-ils réellement ?
Joannes Vermorel: L’IA, d’une manière générale, a été utilisée de manière constante ces deux dernières décennies par les fournisseurs comme un mot à la mode et un terme générique pour englober ce qu’ils avaient. Donc, quand je dis AI Pilots, il s’agit avant tout d’une offre de Lokad. C’est une évolution de notre offre, c’est probablement la plus importante que nous ayons eue depuis des années. Et quelle est la différence ? Eh bien, la différence réside dans le fait qu’un AI Pilot est quelque chose, une application logicielle, ce que nous appelons une série de recettes numériques, qui non seulement exécute le processus de prise de décisions, c’est-à-dire l’aspect purement quantitatif de la supply chain, comme déterminer exactement combien commander, où allouer les stocks, s’il faut augmenter ou baisser les prix, comment planifier précisément la production avec toutes les étapes, etc.
Ce que nous faisions déjà, à cela s’ajoute toutes les opérations banales qui précèdent et suivent, notamment les tâches administratives essentiellement liées à la gestion des master data avant l’analyse des données, puis l’exécution de la décision qui peut impliquer des canaux non structurés, comme les emails par exemple, lorsque vous souhaitez envoyer un email à un fournisseur pour demander l’accélération d’une commande ou, au contraire, le report d’une commande.
Et l’essentiel de cette offre repose évidemment sur des large language models que Lokad n’a pas inventés, mais que nous utilisons de manière intensive depuis 14 mois, voire un peu plus désormais. L’idée clé dans le mode de fonctionnement de Lokad est qu’un seul Supply Chain Scientist doit être capable d’assumer l’entière responsabilité d’une initiative.
Pour les très grandes entreprises, nous pouvons avoir plusieurs personnes sur le projet, mais contrairement à la plupart de nos concurrents, elles ne sont généralement pas spécialisées. Ce n’est donc pas comme si nous prenions une équipe de trois personnes avec M. Database, M. Algorithms, et M. UI et UX. Ce n’est absolument pas ainsi que fonctionne Lokad. Un Supply Chain Scientist est capable de tout faire du début à la fin.
Et c’est l’une des raisons pour lesquelles Lokad a conçu sa propre technologie de cette manière, et nous avons notre propre langage de programmation, un langage de programmation spécifique au domaine appelé Envision, dédié à l’optimisation prédictive des supply chains. Cela peut paraître très étrange d’avoir élaboré un langage de programmation sur mesure, mais en substance, nous, et c’est une décision que j’ai prise en 2012, avions vraiment besoin de quelque chose d’unifié permettant à une seule personne de tout réaliser, du début à la fin.
Jusqu’à il y a quelques années, il s’agissait vraiment d’obtenir les données de transaction brutes à partir des ERPs, des CRMs, de l’EDI, et de tous ces systèmes transactionnels, de les compléter avec une série de tableurs pour toutes les données structurées qui, malheureusement, font partie du shadow IT plutôt que de l’IT classique, puis d’élaborer les recettes numériques pour la prise de décision. Et c’était la responsabilité du Supply Chain Scientist de faire tout cela, puis de concevoir toute l’instrumentation incluant les dashboards et les rapports, pour s’assurer qu’il se convainque lui-même (ou elle-même) que les chiffres étaient corrects, mais aussi pour rassurer nos propres clients quant à la validité de ce que nous faisons, en plus de tous les instruments pour surveiller la qualité des décisions au fil du temps, ainsi que l’infrastructure pour extraire les données des systèmes et réinjecter les décisions dans ces mêmes systèmes.
C’était donc le périmètre de Lokad, et il y avait deux choses que nous ne pouvions pas vraiment faire. Premièrement, nous devions être le récepteur des données, nous ne pouvions pas vraiment les chercher. Et quand je dis chercher, le Supply Chain Scientist pouvait demander les données, nous ne demandions pas aux divisions IT de nos clients de réaliser une transformation sophistiquée quelconque, il s’agissait simplement de vider les tables, vous savez, “select star from table”, boum, vous le faites une fois par jour et le tour est joué. C’étaient donc juste des extractions super simples, mais c’était tout de même la division IT de nos clients qui s’en chargeait.
On ne s’attendait pas à ce que les Supply Chain Scientists cherchent, dans le paysage applicatif de nos clients, les données dont l’initiative avait besoin. La raison est très simple : il existe environ une vingtaine de dialectes SQL, comme Oracle SQL, le dialecte T-SQL de Microsoft SQL Server, MySQL, PostgreSQL, DB2 d’IBM, etc. Il y a donc environ 20 dialectes SQL. Jusqu’à il y a quelques années, un Supply Chain Scientist aurait rencontré d’énormes difficultés, car même si ce que cette personne voulait accomplir était extrêmement simple, comme simplement vider une table, le problème était qu’elle aurait passé littéralement des dizaines d’heures à chercher en ligne pour composer des requêtes triviales, et à chaque message d’erreur, c’était encore elle qui devait intervenir. Même si cette personne connaissait généralement bien les bases de données SQL, ce serait, je dirais, un obstacle majeur de devoir gérer des dialectes de systèmes qu’on ne connaissait pas.
En 2023, avec ChatGPT, le problème est résolu. ChatGPT, en tant qu’assistant programmeur, n’est pas naturellement excellent pour vous permettre de composer des applications sophistiquées, mais lorsqu’il s’agit de composer des requêtes SQL super simples dans des dizaines de dialectes, il est ultra-rapide. Un Supply Chain Scientist va demander la composition d’une requête SQL. Cette personne est également intelligente et relira la requête pour s’assurer qu’elle reflète bien l’intention. Il s’agit simplement d’éliminer l’obstacle de la découverte de la syntaxe, mais une fois que vous avez la syntaxe correcte qui vous est présentée, c’est à peu près explicite.
Si vous voulez l’essayer par vous-même, demandez simplement à ChatGPT de vous fournir un guide pour configurer git sur votre machine et créer un dépôt git ou autre, et vous verrez le type de réponse de très haute qualité que vous pouvez obtenir.
C’est vraiment un game changer, car cela signifie que, soudainement, Lokad, qui forme des Supply Chain Scientists, peut prendre la responsabilité de chercher les données. Et je sais que nous disposons, grâce à ChatGPT, des outils nécessaires pour ne pas nous engager outre mesure en affirmant que nous allons chercher les données. C’est un game changer. Au lieu de demander à l’IT de nous envoyer les données, nous pouvons simplement faire inscrire une adresse IP sur liste blanche, établir une connexion cloud-to-cloud très sécurisée, puis laisser l’équipe de Supply Chain Scientists chasser ses propres données.
Pourquoi cela fait-il une telle différence ? Eh bien, en réalité, même si Lokad n’a besoin que de quelques jours de travail pour une initiative donnée, nous parlons peut-être de 10 à 20 jours de travail pour une initiative d’envergure afin d’obtenir les 20 à 50 tables dont nous avons besoin – il s’agit simplement de vider la table, sans jointures, sans filtrage sophistiqué, c’est très simple. Le problème est que beaucoup de nos clients ont leur propre division IT qui accumule d’énormes arriérés. Je veux dire, littéralement des années d’arriérés, et quand vous avez, disons, trois ans d’arriéré, même si Lokad ne demande que 10 jours, ce sont 10 jours plus trois ans d’arriéré. Ainsi, même si nous ne sommes pas exactement à la toute fin de la file d’attente, mais simplement au milieu, ces 10 jours de travail pour l’IT peuvent prendre jusqu’à un an à être réalisés, et c’était, je dirais, une frustration pour nous : la majorité des retards que nous subissions provenait non pas d’une incompétence ou d’une lenteur de l’IT, mais simplement du fait qu’ils avaient tellement d’arriéré qu’il leur était très difficile d’allouer ces 10 jours.
Ici, nous parlons de quelque chose où, au lieu de demander 10 à 20 jours de travail, il s’agit plutôt de moins d’une journée de travail, voire seulement quelques heures, juste pour ouvrir un accès très sécurisé et restreint aux quelques systèmes dont nous avons besoin. Ensuite, les Supply Chain Scientists eux-mêmes vont examiner la table, mettre en place la logique d’extraction des données et s’assurer que ces extractions sont vraiment, je dirais, légères.
La manière de procéder consiste typiquement à surveiller les performances. Chaque fois que celles de la base de données chutent, cela signifie qu’il se passe beaucoup de choses dans la base de données et, par conséquent, vous souhaitez généralement alléger la pression et retarder votre propre processus de récupération des données. Car, typiquement chez Lokad, nous avons besoin de rafraîchir les données quotidiennement, mais ce n’est pas vraiment urgent. Bien sûr, cela dépend. Il y a des situations où nous avons des délais très serrés, mais très fréquemment, en ce qui concerne les supply chains, si nous retardons la récupération de 30 minutes simplement à cause d’une pointe d’activité sur la base de données, cela ne pose aucun problème.
Le premier engagement consiste à chercher les données nous-mêmes et ainsi éliminer la principale cause de retard afin d’accélérer considérablement les initiatives. Encore une fois, ces retards devenaient très souvent la majeure partie du délai nécessaire pour que l’initiative Lokad passe en production, puisqu’il s’agissait simplement d’attendre que l’IT puisse allouer ces jours.
Le second engagement concerne l’amélioration des Master Data. Et ici, encore, autrefois, face à un catalogue comprenant, disons, 100 000 descriptions de produits, dont certaines sont défectueuses, environ 1 %, il fallait beaucoup de travail pour parcourir ces 100 000 références, identifier les descriptions ou libellés de produit incorrects, ou parfois il peut s’agir simplement d’un point de prix complètement incohérent avec la description. Si c’est une vis et que le prix affiché est de 20 000 dollars, ce n’est probablement pas qu’une simple vis, c’est probablement autre chose, etc. Il y avait de nombreuses vérifications de base qui semblaient évidentes et simples, mais il était très difficile d’automatiser cela et il n’y avait fréquemment pas d’autre alternative que de faire examiner les entrées par une personne pour repérer ce qui était vraiment inadéquat.
Avec un LLM, et potentiellement un LLM capable de traiter également des images, vous pouvez faire beaucoup de choses en ce qui concerne l’examen, la surveillance et l’amélioration de tout ce qui est lié aux Master Data. Dans le cas spécifique de Lokad, c’est la partie Master Data dont nous avons besoin pour piloter les supply chains.
Conor Doherty: Eh bien, il y a beaucoup de choses, merci. J’ai de nombreuses questions auxquelles je souhaite apporter des compléments. Je vais prendre un léger recul, car si je peux résumer tout cela que vous décrivez, et corrigez-moi si je me trompe, un Supply Chain Scientist ayant accès à un bon LLM peut accomplir une quantité incroyable de travail. Un travail qui, jusqu’à présent, aurait pris énormément de temps et impliqué de nombreuses personnes. Maintenant, dans une configuration non à la manière de Lokad, combien de personnes supplémentaires seraient impliquées ? Combien d’intervenants en plus y aurait-il ? Et vous pouvez ensuite aborder l’efficacité, mais juste en termes d’effectif, quelle est la différence entre des Supply Chain Scientists avec LLM et, je ne sais pas, le S&OP par exemple ?
Joannes Vermorel: Nos clients sont généralement étonnés par le fait que, même pour une grande initiative, il suffit de deux ou trois personnes, et toujours les mêmes. Nous avons Lokad, et je suis très fier que Lokad, en tant qu’employeur, parvienne à garder ses collaborateurs pendant longtemps. En définitive, chez Lokad, c’est typiquement 1 % de bout en bout. Si nous avons plusieurs personnes, c’est avant tout pour avoir de la redondance. Un jour, vous vous concentrez sur une partie du pipeline et je m’occupe de l’autre, puis le jour suivant, nous échangeons. Ce n’est pas comme si les gens ne se spécialisaient pas : chaque personne possède une compétence couvrant l’ensemble du pipeline. Il y a quelques variations et certaines personnes ont une spécialité particulière, mais dans l’ensemble, les gens peuvent vraiment se substituer les uns aux autres.
Nos concurrents, c’est tout autre chose. Même une petite initiative implique littéralement une demi-douzaine de personnes. Vous aurez le chef de projet, uniquement là pour coordonner les autres, puis le consultant, le UX designer, le configurateur, l’administrateur de bases de données, le spécialiste réseau, et potentiellement un programmeur, un ingénieur logiciel pour les personnalisations non natives. Encore une fois, Lokad est une plateforme programmatique, tandis que la plupart de nos concurrents ont des plateformes non programmatiques. Ainsi, chaque fois que vous voulez obtenir un comportement programmatique, vous devez avoir un ingénieur logiciel à part entière qui va littéralement implémenter, avec un langage de programmation généraliste comme Java ou Python, les éléments manquants. Donc, chez Lokad, ce n’est vraiment pas le cas. Je dirais qu’en général, nos concurrents font appel à une dizaine de personnes. Les initiatives S&OP peuvent impliquer plusieurs dizaines de personnes, mais il ne s’agit pas nécessairement d’autant de compétences différentes, c’est principalement des personnes issues de départements divers et très souvent, ce n’est pas très axé IT.
Donc, Lokad, quand je dis une personne contre une dizaine, cela se compare à nos concurrents qui vendent des APS, des systèmes avancés de planification ou des systèmes d’optimisation de stocks, ce genre de logiciels d’entreprise.
Conor Doherty: Merci. Et pour revenir sur un autre point que vous avez mentionné au début en parlant des Supply Chain Scientists, vous avez donné l’exemple des différents dialectes SQL, puis le Supply Chain Scientist qui, selon qu’il maîtrise ou non le dialecte spécifique du client, validerait ou surveillerait les scripts générés automatiquement, car les LLM hallucinent occasionnellement.
Eh bien, à ce sujet, les LLM hallucinent très souvent. Certes, cela s’améliore, mais vous pouvez demander à un LLM, avec un morceau de texte, “Trouvez ce mot caché, le voyez-vous ?” et il dira oui, alors qu’il n’est pas là. Je sais qu’il n’est pas là, vous savez qu’il n’est pas là. Comment, à grande échelle, pouvez-vous assurer la sécurité et surveiller le contrôle qualité lorsque vous exploitez des LLM de manière automatisée ?
Joannes Vermorel: Les hallucinations, ou confabulations comme je préfère les appeler, se produisent réellement lorsque vous utilisez le LLM comme une base de connaissances sur tout. Si vous utilisez les LLM comme base de connaissances de tout, alors cela arrive. Si vous demandez des articles médicaux en disant “Donnez-moi une liste d’articles sur cette pathologie”, il vous fournira quelque chose de globalement correct. Les auteurs existent fréquemment, ils ont publié, ils ont des éléments dans ce domaine, ils ont publié des articles qui étaient dans le même registre, mais pas tout à fait. Là encore, considérez cela comme si vous demandiez à un scientifique de se souvenir de choses de mémoire.
C’est très difficile, diriez-vous, et si vous dites qu’il faut le faire, ils proposeront probablement quelque chose d’à moitié plausible, avec des noms corrects de collègues ou de chercheurs, des titres semi-corrects, ce genre de choses. C’est donc une situation où vous obtenez des confabulations, mais vous y invitez en quelque sorte. Je veux dire, vous demandez aux LLM de se comporter comme une base de données de tout, donc c’est très difficile, et vous allez rencontrer ce genre de problème.
Il en va de même avec les dialectes SQL : vous essayez et vous obtenez quelque chose qui est approximativement correct. Si vous demandez “Je veux lire une table”, il va exécuter “select star from table”, et ainsi de suite. Il ne vous donnera pas, par exemple avec GPT-4, lorsque vous demandez à lire une table, “drop table”. Il peut vous fournir une syntaxe légèrement inadéquate, donc vous testez votre requête SQL, vous obtenez un message d’erreur, vous apportez une petite modification et ça fonctionne. Mais voyez-vous, c’est toujours globalement correct. Si vous demandez à lire la base de données, il ne produira pas une commande qui supprime une table ou modifie les taux de permission de la base de données.
Il en va de même lorsque vous demandez des connaissances inventées. Par exemple, si vous demandez “D’accord, j’ai un compresseur industriel de 20 kilowatts de puissance, quel est son point de prix ?”, si vous demandez à GPT, il pourrait dire probablement quelque chose comme 10 000 $. Il s’agit simplement d’une estimation approximative. C’est littéralement inventé. C’est plausible, mais est-ce correct ? Probablement pas, et cela dépend de centaines de variantes car il existe tant de compresseurs différents pour diverses situations.
Ainsi, en fin de compte, les confabulations ne se produisent pas au hasard. Il existe des types de tâches bien spécifiques où elles surviennent beaucoup plus fréquemment. Je dirais donc que lorsque vous y invitez, lorsque vous utilisez le LLM comme une base de données de tout, il vaut mieux vérifier soigneusement. Cela peut être extrêmement utile : par exemple, pour les dialectes SQL, il vous donnera une indication sur le genre de mots-clés à utiliser, sur l’aspect de la syntaxe, et il pourra commettre une petite erreur, oublier une virgule ou quelque chose du genre, mais avec quelques itérations, vous finirez par l’avoir juste. Surtout parce qu’une fois que vous avez la requête SQL, vous pouvez la tester sur la base de données, voir le résultat et le valider, ce qui vous offre une boucle de rétroaction instantanée pour vérifier cela.
Si vous souhaitez détecter, disons, des étiquettes de produits étranges, des étiquettes qui paraissent douteuses, comme lorsqu’il manque la description d’un produit, c’est bien votre étiquette de produit, d’accord, c’est évidemment erroné. Mais il peut y avoir toutes sortes d’erreurs. Par exemple, vous pouvez avoir une étiquette de produit qui indique “tournevis cruciforme” — c’est en français — et donc le problème, c’est qu’elle est simplement en français, alors qu’il s’agit, je pense, d’un tournevis à tête Phillips. Et donc, encore une fois, vous pouvez demander certaines choses, mais à un moment donné, ce n’est pas parfait, c’est une question de jugement. Un humain ferait exactement la même erreur, donc vous ne pouvez pas vous attendre à ce que le LLM soit un oracle final capable de répondre correctement à chaque question. À un moment donné, si vous effectuez une tâche telle que passer en revue les 100 000 produits de votre catalogue pour détecter des anomalies dans les étiquettes, le LLM produira des faux positifs et des faux négatifs, tout comme un humain. Mais ce qui est intéressant, c’est que vous pouvez en fait mesurer le taux de faux positifs et de faux négatifs puis décider si cela en vaut la peine ou non. Et très souvent, vous obtenez quelque chose de plutôt bon, quelque chose qui vous apporte beaucoup de valeur, même s’il fait encore quelques erreurs.
Conor Doherty: Progrès, pas la perfection.
Joannes Vermorel: Exactement. Si vous pouvez réduire de 90 % vos problèmes de données de référence avec quelque chose de très bon marché et pouvant être réexécuté, littéralement, en quelques heures sans surveillance, c’est très bien.
Conor Doherty: Il y a également la valeur issue du temps qui n’a pas été passé à faire cela manuellement, ce temps que vous auriez pu consacrer à autre chose qui génère ou apporte de la valeur. Ainsi, il existe là des moteurs directs et indirects de valeur.
Joannes Vermorel: De plus, la réalité, c’est que lorsque vous effectuez une tâche très répétitive pendant une heure, vous pouvez atteindre un certain niveau de qualité. Mais si vous la faites pendant 100 heures, disons à l’heure 67, je veux dire, en général, les humains ne sont pas des machines à performance constante. Au bout de quelques heures, la concentration baisse et donc le nombre de faux positifs et de faux négatifs va probablement exploser, même avec un employé assez diligent.
Conor Doherty: Merci. Et je tiens à signaler que nous avons en fait quelques questions du public qui abordent des sujets que j’allais poser, donc je vais passer sur certaines choses mais elles seront traitées dans les questions du public. Mais une dernière réflexion ici, lorsque vous parlez des Supply Chain Scientists, de l’AI Pilot — et nous y reviendrons plus tard dans les questions —, mais le Supply Chain Scientist, un AI Pilot et le client, comment cette orchestration fonctionne-t-elle au quotidien ? Le client a-t-il accès, interagit-il avec le LLM ?
Joannes Vermorel: Typiquement, nous considérons que toutes les recettes numériques élaborées par les Supply Chain Scientists constituent l’AI Pilot. C’est cet élément qui pilote la supply chain au quotidien. Il fonctionne sans surveillance et génère les décisions. Maintenant, avec les LLMs, il gère également les subtilités de la préparation des données et les décisions des bons de commande. Par exemple, la pré-décision consisterait à demander aux fournisseurs leur MQS. Vous devez récupérer ces informations, si elles manquent ou ne sont pas à jour, il faut les modifier. Les LLMs peuvent vous aider à obtenir cela. La post-décision consisterait à envoyer un e-mail pour demander une ETA, l’heure d’arrivée estimée, pour les commandes si vous n’avez pas d’EDI en place ou si vous n’avez pas de pont, ou bien demander d’accélérer ou de reporter une commande. Ce sont ce genre de subtilités qui surviennent ensuite, où Lokad peut générer la décision de demander d’accélérer une commande, mais sans prendre en charge les détails qui consistent simplement à composer un e-mail et l’envoyer.
Tout cela constitue à peu près l’AI Pilot et représente la grande recette numérique qui gère le processus de bout en bout. Tout cela est implémenté par le Supply Chain Scientist. C’est donc une extension de périmètre pour Lokad. Le Supply Chain Scientist est en fait le copilote. Et considérez-le vraiment comme, lorsque je dis pilote, je veux dire un pilote automatique dans un avion. D’ailleurs, de nos jours, les manœuvres les plus difficiles des avions se font en mode autopilote. Lorsque vous avez des aéroports impressionnants comme l’ancien aéroport de Hong Kong, avec un nouveau beaucoup plus facile, mais avec un aéroport littéralement situé en plein milieu d’immeubles de grande hauteur, l’autopilote pour ces manœuvres est indispensable. Donc c’est fait, c’est entièrement la machine, et les gens ne font qu’observer.
Ici, le Supply Chain Scientist conçoit les recettes numériques et joue le rôle de copilote. Il décide, il oriente pratiquement la navigation pour diriger le processus, puis il élabore le plan et le parcours pour le pilote. Mais fondamentalement, le Supply Chain Scientist joue le rôle de copilote, déterminant les directions, anticipant et veillant à ce que le pilote puisse opérer aussi harmonieusement que possible. Pour les ajustements à haute fréquence, c’est le pilote qui intervient, et non le copilote. Le client, quant à lui, occupe le rôle du capitaine.
Vous savez, un peu comme dans la vieille série télévisée Star Trek, où le capitaine est assis dans son fauteuil et donne des instructions de très haut niveau à l’équipage. Ainsi, dans cette configuration, le client définit la stratégie et donne les directives globales. Il revient alors au Supply Chain Scientist de mettre cela en œuvre, et au pilote d’exécuter toutes les micro-ajustements nécessaires ou toutes les décisions quotidiennes requises pour la supply chain, puis d’exécuter la supply chain en tant que telle.
Conor Doherty: Et cela concerne aussi, encore une fois, pour bien clarifier — car nous n’en avons pas parlé — que c’est en plus de toutes les tâches quantitatives automatisées déjà réalisées. Elles existent depuis des années. Donc, au cas où quelqu’un écouterait en se disant “Ah, ce ne sont que les tâches qualitatives”, nous parlons ici de bout en bout. Oui, quantitatives, comme la factorisation des economic drivers, la génération d’allocation, les achats, la tarification, tout cela est également piloté par l’IA et automatisé.
Ainsi, le Supply Chain Scientist supervise à la fois ces consoles, qu’elles soient quantitatives ou qualitatives.
Joannes Vermorel: Exactement. Et la raison pour laquelle Lokad a enfin commencé à adopter ce mot-clé IA — c’est un terme générique —, c’est que nous y ajoutons, en y intégrant, des LLMs. Nous disposions déjà de machine learning avec le differentiable programming et l’optimisation stochastique, mais maintenant nous y ajoutons des LLMs. Et cela constitue littéralement une boîte à outils très complète.
L’effet est littéralement, pour les clients, des supply chains pouvant fonctionner sans surveillance pendant des semaines. Les gens sont étonnés de voir combien de temps, une fois ces moteurs économiques en place, il est possible d’opérer totalement sans surveillance. La beauté de cela, c’est qu’il n’est pas nécessaire de procéder à des micro-ajustements. Par exemple, les ajustements aux prévisions sont, pour la plupart de nos clients, totalement inexistants. Et la plupart des autres ajustements sont également réalisés de manière complètement automatique, tels que l’introduction de nouveaux produits, le retrait progressif d’anciens produits, l’introduction de nouveaux fournisseurs et la suppression des fournisseurs non performants.
Ainsi, tout cela relève en quelque sorte du quotidien, et lorsque les recettes sont correctement établies, elles nécessitaient déjà par le passé peu d’interventions. Mais avec cet AI Pilot qui intègre les LLMs, l’ajout d’un nouveau fournisseur dans le processus, toutes ces opérations peuvent nécessiter encore moins d’interventions manuelles qu’auparavant.
Conor Doherty: D’accord, Joannes, merci. Nous en sommes à environ 40 minutes. Il y a des questions auxquelles répondre, et je vais maintenant nous orienter vers cela. Mais avant de le faire, en guise de résumé ou de réflexion finale, toujours dans le contexte de la conversation bien plus large que nous avons eue il y a un mois et que nous avons aujourd’hui, quel est le bilan pour le praticien de la supply chain ainsi que, disons, pour les équipes dirigeantes qui supervisent le praticien de la supply chain moyen ? Quel est le message clé ou l’action à entreprendre pour eux ?
Joannes Vermorel: Je pense que d’ici une décennie, cette vision des AI Pilots, peut-être sous un autre nom, deviendra la norme. Peut-être qu’elle sera tellement répandue que l’on parlera simplement de supply chain sans évoquer d’AI Pilots pour la supply chain. Et il deviendra évident que, dans une supply chain, vous disposez de ces AI Pilots. C’est comme lorsqu’on parle d’un ordinateur : vous ne dites pas “j’ai un CPU, j’ai de la mémoire”, c’est acquis qu’un ordinateur possède un CPU, donc vous ne le mentionnez même pas.
Pour moi, d’ici une décennie, ces fonctions seront largement automatisées et Lokad, avec ces AI Pilots, propose une offre packagée qui accomplit cela avec un Supply Chain Scientist. Pour nos clients, cela signifie que la pratique de la supply chain change de nature. Cela signifie qu’ils disposent de ces AI Pilots capables de libérer une grande bande passante. Nous libérions déjà la bande passante pour le processus décisionnel et les calculs complexes. Mais maintenant, nous libérons également le temps consacré à la surveillance de la liste des SKUs, de la liste des fournisseurs, de la liste des clients, simplement pour maintenir les données de référence correctes, propres et fiables. Tout cela disparaît et élimine le besoin d’interventions manuelles qui étaient très souvent, de toute façon, peu quantitatives. Il fallait corriger une étiquette, réparer une entrée, supprimer un doublon ou autre. Encore une fois, Lokad s’en occupera.
En somme, c’est une amélioration massive de la productivité. Je pense qu’avec certains clients, nous parvenons littéralement à réduire de 90 % les effectifs dédiés aux tâches répétitives. La réalité, c’est que désormais vous disposez de plus de temps pour vous consacrer à ce qui est beaucoup plus difficile à automatiser, et je crois que cela apporte une plus grande valeur. Cela consiste vraiment à réfléchir soigneusement à la stratégie, à passer beaucoup plus de temps à examiner les options, à déterminer ce que vous devriez explorer au lieu de gaspiller votre temps sur des tableurs.
Prenez donc le temps de réfléchir longuement aux problèmes difficiles, puis parlez aux fournisseurs et aux clients, et engagez de véritables conversations approfondies afin de pouvoir organiser votre propre supply chain pour satisfaire votre fournisseur, qui sera alors enclin à vous offrir de meilleurs prix, une meilleure qualité, une meilleure fiabilité, etc. Si vous vous organisez pour répondre aux besoins de vos fournisseurs, cela peut sembler un peu contre-intuitif, comme si l’on disait “Oh fournisseurs, je suis le client, c’est à vous de vous adapter.” Mais si vous pouvez mieux accommoder vos fournisseurs, c’est un effort d’équipe qui permet d’obtenir une plus grande fiabilité et de meilleurs prix.
Et vous pouvez faire le même effort avec votre client, car c’est la même collaboration qui doit se mettre en place. Encore une fois, cela nécessite beaucoup de discussions intelligentes, et ce sont le genre de choses que les LLMs ne peuvent pas fournir de nos jours. Je crois donc que chez Lokad, nous pouvons automatiser les tâches que nous apprécions — les subtilités à faible valeur ajoutée et les tâches administratives banales — et laisser aux humains le soin de s’occuper des aspects stratégiques, voire semi-stratégiques. J’utilise le terme semi-stratégique parce que vous parlerez à un client à la fois, élaborerez la stratégie en résumant le tout, créerez une vision, puis soutiendrez la direction de la supply chain afin qu’elle dispose d’une stratégie très claire et bien fondée pour son entreprise.
Conor Doherty: Donc, pour reprendre deux exemples afin de conceptualiser cela, par exemple les décisions de bas niveau, comme parcourir un tableur Excel en se disant “Oh, il est écrit en bloc de couleurs, donc ça doit être noir”, ce qui revient à corriger automatiquement cela — c’est trivial, c’est banal, ça ne vaut pas votre temps. “Dois-je ouvrir un entrepôt à Hambourg ?” Stratégique.
Joannes Vermorel: Oui, c’est stratégique. De plus, le problème est qu’il existe tellement d’options. Pour un entrepôt, vous pourriez vous demander : dois-je acheter, louer, quel type de contrat, quel est le degré de mécanisation, faut-il prévoir un contrat pour l’équipement afin de pouvoir le restituer, devrais-je louer l’équipement ou non ? Il y a littéralement des centaines de questions et très souvent, lorsque les gens doivent consacrer 99 % de leur capacité mentale à des tâches administratives, ils n’ont plus de temps à consacrer à ces grandes questions.
Vous voyez, si j’appliquais la loi de Parkinson, je dirais que j’ai vu de nombreuses entreprises où, en calculant le temps total passé sur quelque chose comme les classes ABC, chaque année, on parle d’années-homme investies dans les classes ABC. Et lorsqu’il s’agit de décider pour un nouvel entrepôt, il s’agit de semaines de travail. Mais vous voyez le déséquilibre : les gens consacrent littéralement, collectivement, des années de temps humain à quelque chose d’entièrement absurde comme les classes ABC. Et lorsqu’il s’agit d’un investissement de 50 millions d’euros pour ouvrir un entrepôt, ce sont littéralement quelques semaines, puis bam, une décision est prise. Vous voyez, cela devrait être inversé.
Conor Doherty: Très bien, merci pour cela. Sur ce, je vais passer aux questions du public. Merci beaucoup. N’hésitez pas à les soumettre jusqu’à ce que j’arrête. Alors, Joannes, ceci vient de Massimo. Pourriez-vous nous en dire plus sur la manière dont l’IT peut tirer parti des AI Pilots pour réduire le backlog et pourquoi vous pensez que cette approche devrait être proposée ?
Joannes Vermorel: Les AI Pilots ne visent pas à réduire les arriérés de l’IT. Il s’agit de faire face au fait que l’IT accumule des années d’arriérés. Ainsi, notre plan chez Lokad n’est pas de diminuer l’arriéré de l’IT. Il faut repenser l’IT de la même manière qu’Amazon l’a fait. Ce serait l’objet d’un autre épisode. Je dirais qu’il suffit de consulter le mémo de 2002 de Jeff Bezos concernant les APIs chez Amazon. L’essentiel, c’est que tous les départements d’une entreprise moderne ont besoin d’une multitude d’outils logiciels. Chaque division — marketing, finance, comptabilité, supply chain, ventes — souhaite disposer de tonnes d’outils logiciels, et tout cela retombe sur les épaules de l’IT. L’IT est en train de s’effondrer sous ce poids.
Donc, mon propos est que chez Lokad, nous sommes des spécialistes de la supply chain. Nous n’allons pas traiter de tout ce qui concerne le marketing, les ventes, la comptabilité, etc. Ce que nous affirmons, c’est qu’avec les LLMs, nous pouvons libérer l’IT de la gestion de Lokad. En fin de compte, nous passons d’environ 10 à 20 jours de travail de l’IT pour mettre en route l’initiative de la Supply Chain Quantitative — c’est-à-dire pour construire le pipeline — à seulement quelques heures. Ainsi, nous ne résolvons pas l’arriéré. L’IT fait ce qu’il doit faire. Il peut également bénéficier des LLMs, mais dans leur cas, les situations sont beaucoup plus diverses, beaucoup plus difficiles.
Donc, ma proposition n’est pas que les LLMs peuvent réellement aider l’informatique à réduire leurs arriérés. C’est simplement une manière pour Lokad, dans ce cas précis, de dire, “Eh bien, au lieu d’ajouter 20 jours de plus à l’arriéré, nous ajoutons simplement environ quatre heures et c’est réglé.” C’est ainsi que nous gérons l’arriéré. Et plus généralement, la solution à ces années d’arriéré est que chaque division doit internaliser la majorité des aspects logiciels. Vous voyez, le problème des années d’arriéré, c’est que, globalement, les entreprises exigent trop de l’informatique. Chaque division devrait adopter des pratiques digitales – marketing, ventes, comptabilité, etc. Vous ne devriez pas demander à l’informatique de résoudre tous ces problèmes pour vous. Vous devriez avoir des experts digitaux dans chaque domaine pour le faire. Et c’est exactement l’essence de ce mémo de 2002, si je ne confonds pas, de Jeff Bezos à son équipe. C’est un mémo très célèbre. Vous pouvez taper “famous memo Bezos” car il disait, en substance, “Vous avez deux semaines pour élaborer un plan permettant à chaque division d’exposer toutes vos données afin que nous n’ayons pas ce genre de siloing et de jeux de pouvoir qui se déroulent dans l’entreprise, chez Amazon.”
Et Bezos concluait : “Tout manager qui n’aura pas un plan sur mon bureau d’ici deux semaines sera viré ou quelque chose du genre.”
Conor Doherty: D’accord, merci. Ce commentaire suivant, et c’est une question que je n’ai pas posée car j’ai vu qu’elle était mentionnée dans les commentaires, donc elle est formulée comme un commentaire mais considérez-la comme une question. Ceci vient de Jesse. “Un Supply Chain Scientist plus un LLM sonne toujours comme un copilote. Alors, encore une fois, distinguez AI Pilot de copilote.”
Joannes Vermorel: La raison pour laquelle nous disons que c’est un pilot, c’est que nous avons certains clients pour lesquels, pendant des semaines, toutes les décisions sont générées puis exécutées sans supervision. Et quand je dis sans supervision, je le pense vraiment. Lors des confinements de 2020, nous avons même eu une entreprise où, pendant 14 mois, tous les employés de bureau restaient littéralement chez eux, ne travaillant pas, payés par l’État parce que celui-ci accordait des subventions en Europe. Plusieurs États accordaient des subventions pour rester essentiellement chez soi et ne pas travailler. Et donc, c’était la situation. Ainsi, nous avons vécu cela, et quand vous avez une supply chain qui fonctionne pratiquement sans supervision pendant 14 mois, je l’appelle un pilot, et non un copilote. S’il n’y a personne pour superviser les chiffres générés par le système, je pense vraiment que c’est un pilot.
Mais nous n’utilisions pas de LLM à l’époque. Et c’était une situation où les données étaient propres et il n’y avait aucun besoin dramatique d’améliorer cette gestion des données de référence. Et c’était un client qui avait une maturité très élevée en termes d’intégration EDI, etc. Donc, les choses qui étaient nécessaires avant et après étaient très, très limitées.
Bref, revenons à la question du copilote. La plupart des concurrents de Lokad affirment qu’ils proposent un copilote. Et en effet, la manière dont ils procèdent est complètement différente. Lokad, le Supply Chain Scientist, utilise un langage de programmation. Ainsi, quand nous utilisons un LLM, c’est pour générer, pour nous aider à générer des morceaux d’un programme. C’est à cela que nous nous en servons.
Ainsi, un LLM est utilisé pour générer essentiellement des morceaux de programmes qui peuvent être des dialectes SQL ou quelques autres choses. Ensuite, nous développons le pilot, qui fonctionne ensuite sans supervision.
Nos concurrents, en particulier ceux qui affirment qu’ils vont apporter de l’IA conversationnelle, une interface utilisateur conversationnelle sur le marché, font quelque chose de complètement différent. Ce qu’ils font, c’est généralement de la génération augmentée par récupération (RAG). Ils composent une invite. Ils vont – c’est littéralement ce que font tous nos concurrents qui affirment actuellement faire de l’IA avec des LLM dans le domaine de la supply chain – composer, disons, une douzaine d’invites correspondant à divers scénarios. Ensuite, après l’invite, ils injectent des données récupérées de la base de données, vous savez, qui peuvent être des statistiques descriptives de base. Ainsi, ils injecteraient quelques dizaines de nombres, les ventes moyennes de la semaine dernière, du mois dernier, de l’année dernière, ou autre, des statistiques de base qui correspondent au scénario. Puis ils ajouteraient la requête supplémentaire de l’utilisateur, et le LLM complèterait la réponse.
Vous voyez, cela montre encore une fois que les LLM se limitent à la complétion de texte. Vous composez un texte et il le complète. Et dans la génération augmentée par récupération, la partie récupération consiste simplement à extraire quelques nombres de la base de données, puis à composer. Mais en fin de compte, vous obtenez quelque chose qui vous permet de poser une question. Cependant, la réalité est que, si vous n’êtes pas complètement perdu, vous pouvez lire les nombres directement à l’écran. Il n’y a pas de magie. Ainsi, fondamentalement, il ne peut répondre qu’aux questions auxquelles un tableau de bord répond immédiatement.
Donc, oui, si vous ne connaissez pas vraiment la définition de chaque nombre, il peut vous l’expliquer. Mais vous pouvez aussi, c’est ce que fait Lokad, disposer d’une fiche mémo qui fournit la description en une ligne associée à chaque tableau de bord, pour chaque nombre présent sur celui-ci. Et cela remplira effectivement exactement le même rôle, sans intervention d’IA.
En fin de compte, je suis extrêmement sceptique quant à ces IA conversationnelles, ces copilotes, car, en substance, ce ne sont que des gadgets superposés à des systèmes existants qui n’ont jamais été conçus pour aucun type de système d’apprentissage automatique, et encore moins pour les LLMs.
C’est pourquoi, à ma connaissance, tous nos concurrents proposent des copilotes où, en substance, ils disposent de quelque chose qui est, disons, un chatbot superposé à des tableaux de bord. Mais il n’automatise rien. Il ne vous permet pas d’automatiser quelque type d’AI Pilot. C’est, oui, un gadget sur un système hérité.
Conor Doherty: Merci. Et en fait, un exemple que vous avez cité dans cette réponse offre une bonne transition ici. De la part d’un spectateur, Durvesh, avez-vous des projets d’open source d’Envision pour un usage éducatif ou pour les petites entreprises ? Et peut-il être programmé avec des règles pour bénéficier aux entreprises B2B, comme celles du secteur chimique, qui nécessitent une saisie manuelle étendue ?
Joannes Vermorel: Aussi surprenant que cela puisse paraître, l’analyse des processus est très importante. Mais pas nécessairement de la manière dont les gens l’imaginent. La réalité est qu’en supply chain, les entreprises ont eu quatre ou cinq décennies pour inventer une multitude de processus inventés. Et j’insiste sur “inventés”. La supply chain est un jeu de bureaucratie. Elle possède un noyau bureaucratique. Le jeu de la supply chain au cours des cinq dernières décennies a été une manière d’organiser le travail, car il est impossible qu’une seule personne gère tous les SKU, tous les entrepôts, toutes les implantations, tous les produits. Vous devez donc diviser pour régner, en répartissant la charge de travail sur des dizaines, voire des centaines de personnes dans les grandes, très grandes entreprises.
Ainsi, vous vous retrouvez avec une situation où 90 % de vos processus ne reflètent que les complications émergentes dues au fait que la charge de travail est répartie sur de nombreuses personnes. Vous voyez, ce sont des processus accidentels, et non des processus essentiels. Donc, je dirais oui, vous devez réaliser l’analyse des processus, mais attention, 90 % des processus existants ne traitent pas le problème fondamental auquel votre supply chain est confrontée, mais des problèmes accidentels créés par le fait qu’il faut beaucoup de personnes pour résoudre les 10 % du problème à aborder.
Dans des industries telles que le traitement chimique, où il y a de nombreux flux et dépendances, c’est très compliqué. Par exemple, lorsque vous avez des réactions chimiques, vous allez obtenir des sous-produits. Ainsi, à chaque fois que vous produisez un composé, vous produisez également autre chose. Ce “autre” peut être vendu ou utilisé dans un autre processus. Il faut tout coordonner. Vous avez des tonnes de contraintes, des processus qui fonctionnent par lots et des processus qui fonctionnent en continu. C’est très compliqué.
Mais la réalité, c’est que la plupart des processus, au lieu de se concentrer sur la physicalité du problème – le fait que, par exemple, dans une industrie de process, vous avez des réactions chimiques avec des entrées et sorties très spécifiques, le tout étant clairement défini et connu – au lieu de se concentrer sur la couche de base de la réalité physique de votre entreprise, l’analyse des processus pourrait simplement rétroconcevoir des processus qui auront disparu lorsque vous aurez mis en place l’AI Pilot.
L’élément intéressant est que, lorsque vous adoptez le style AI Pilot, vous n’avez plus besoin de cette approche de division et de conquête. Il s’agit d’un ensemble unifié de recettes numériques qui résolvent le problème de bout en bout. Ainsi, tous ces problèmes de coordination, qui étaient résolus par autant de processus, disparaissent tout simplement.
Mon expérience est que 90 % de ces processus auront disparu une fois que nous aurons terminé. C’est pourquoi je dis qu’il est très important de garder un focus net sur la couche physique de base de votre supply chain, plutôt que sur les processus inventés qui ne servent qu’à coordonner de nombreuses équipes. Ces éléments ne vont pas être améliorés, ils vont être remplacés par l’AI Pilot.
Conor Doherty: Merci. Et en fait, un exemple que vous avez cité dans cette réponse offre une belle transition ici. De la part d’un spectateur, Durvesh, avez-vous des projets d’open source d’Envision pour un usage éducatif ou pour les petites entreprises ? Et peut-il être programmé avec des règles pour bénéficier aux entreprises B2B, comme celles du secteur chimique, qui nécessitent une saisie manuelle étendue ?
Joannes Vermorel: Oui, nous prévoyons d’open sourcer Envision à un moment donné. Mais laissez-moi d’abord expliquer pourquoi. Dans ce monde du logiciel d’entreprise, nous avons une documentation publique pour Envision. La plupart de mes pairs disposent de langages spécifiques à un domaine (DSL), mais ils ne sont pas documentés publiquement. Dassault Systèmes a acheté une autre entreprise appelée Quintiq. À l’époque, elle venait avec un DSL, qui n’était pas documenté publiquement. Ainsi, il existe littéralement, dans le domaine de la supply chain, d’autres entreprises qui disposent de DSL et qui ne sont pas publics. Chez Lokad, nous documentons tout publiquement et nous disposons d’un free sandbox environment pour Envision. Nous proposons même des free workshops afin que vous puissiez enseigner ou apprendre Envision avec des exercices. Nous faisons donc bien plus.
Maintenant, en ce qui concerne l’open source d’un langage, cela fait partie du plan, mais il est encore trop tôt. Pourquoi ? Parce qu’Envision est toujours en pleine évolution rapide. Vous voyez, l’un des problèmes auxquels vous êtes confronté lorsque vous open sourcez un compilateur, c’est que le compilateur est un programme qui vous permet de compiler votre script en quelque chose qui s’exécute. Dès que vous open sourcez votre compilateur, cela signifie que des gens vont exploiter le code Envision, dans le cas de Lokad, à l’état sauvage. Et Lokad perd la possibilité de mettre automatiquement à jour ces scripts. La réalité est que, ces dix dernières années, Lokad a modifié le langage de programmation Envision des centaines de fois. Ce langage n’est pas stable. Si vous regardez mon livre, le livre de la Supply Chain Quantitative qui a maintenant environ six ans, la syntaxe d’Envision a évolué de façon spectaculaire. Vous pouvez apercevoir une syntaxe vestigiale qui n’existe plus dans Envision.
Alors, comment gérons-nous ce changement constant de syntaxe ? Eh bien, chaque semaine chez Lokad, nous effectuons des versions hebdomadaires le mardi et ce que nous appliquons, ce sont des réécritures automatisées pour tous les scripts Envision exploités sur les plateformes de Lokad. C’est donc l’une des propriétés clés d’Envision : avoir une très grande affinité pour l’analyse statique. Et l’analyse statique est, d’ailleurs, une branche de la conception et de l’analyse des langages. Quand je dis langage, je veux dire langage informatique, qui vous permet d’obtenir des propriétés des programmes sans les exécuter. Et grâce à l’analyse statique, ce que nous pouvons faire, c’est réécrire automatiquement un script existant de l’ancienne syntaxe à la nouvelle. Et nous faisons cela automatiquement le mardi. Et typiquement, lors d’une mise à jour, nous acceptons pendant quelques jours l’ancienne syntaxe et la nouvelle. Nous effectuons les réécritures automatisées puis, lorsque nous constatons que l’ancienne syntaxe n’existe plus, nous verrouillons, via un feature flag, le fait que seule la nouvelle syntaxe existe.
Et chez Lokad, nous avons déjà déployé plus de 200 de ces réécritures automatisées. Typiquement, nous les réalisons lors de nos sorties hebdomadaires le mardi, mais nous avons généralement environ deux réécritures par mois, et ce, depuis une décennie. Tant que ce processus se poursuit, chez Lokad, nous ne pouvons pas raisonnablement publier Envision en open source. Cela viendra en temps voulu, mais je ne veux pas répéter l’énorme erreur commise avec Python. La mise à niveau de Python 2 vers Python 3 a pris une décennie à la communauté Python et a été incroyablement douloureuse. Les entreprises ont mis des années dans cette mise à niveau, un cauchemar qui a duré une décennie. C’était vraiment, vraiment une grosse erreur. Même Microsoft, avec la mise à niveau de C# du .NET framework vers .NET core, a mis une demi-décennie et cela a été une très grande douleur. Et c’est là encore le problème : une fois que vous avez un compilateur open source à l’état sauvage, vous ne contrôlez pas le code. Donc, si vous souhaitez apporter des modifications au langage, vous devez collaborer avec votre communauté. Cela rend le processus extrêmement lent, extrêmement douloureux et, au final, vous n’éliminez jamais vraiment toutes les mauvaises caractéristiques de votre langage.
Si l’on regarde Python, par exemple, la manière dont la programmation orientée objet a été introduite dans Python, la syntaxe, ah, elle est maladroite. On peut vraiment sentir que Python n’a pas été conçu pour la programmation orientée objet. Ce fut une addition ultérieure à la fin des années 90 et la syntaxe est plutôt médiocre et maintenant, elle est là pour toujours. Et d’ailleurs, chaque langage présente cela. En C#, on a le mot-clé volatile qui ne sert plus à rien. Le C++ est coincé à jamais avec l’héritage multiple. C’était une erreur. L’héritage multiple était une mauvaise décision de conception qui complique tout, etc. La seule manière d’éviter ces grandes erreurs, chez Lokad, nous avons commis beaucoup d’erreurs majeures dans la conception d’Envision, mais nous les corrigeons une par une et nous sommes encore en processus, surtout lorsque de nouveaux paradigmes émergent. Par exemple, la differentiable programming était un nouveau paradigme majeur et nous avons dû réingénier le langage lui-même pour l’accommoder.
D’ailleurs, il existe une méga-proposition majeure pour Swift, proposée par Apple, pour faire de la differentiable programming une citoyenne de première classe dans Swift. Mais cela ne se produira probablement pas de sitôt. C’est une refonte majeure, majeure. Actuellement, le langage le plus proche d’avoir la differentiable programming en tant que citoyenne de première classe serait Julia, et même là, c’est beaucoup de bricolage.
Conor Doherty: Merci encore. Il nous en reste trois à traiter. La prochaine provient de Victor. Il s’agit globalement d’IA. Comment l’IA aborde-t-elle les goulets d’étranglement aléatoires étant donné qu’elle opère sur de grands ensembles de données pour prédire des scénarios plausibles ou des problèmes récurrents?
Joannes Vermorel: Soyons clairs, quand nous parlons d’IA, il s’agit d’un ensemble de techniques. Chez Lokad, nous utilisons typiquement des LLMs, du differentiable programming et de l’optimisation stochastique. Le differentiable programming sert à l’apprentissage, l’optimisation stochastique sert à optimiser sous contraintes en présence d’incertitude, le modèle probabiliste est généralement régressé avec le differentiable programming, et les LLMs servent à créer ce moteur de modélisation universel et résistant au bruit.
Lorsque vous abordez la supply chain avec des outils probabilistes, la plupart des tâches implicites dans cette question disparaissent. C’est là toute la beauté de la prévision probabiliste, ces prévisions ne sont pas plus précises, elles sont tout simplement beaucoup plus résilientes au bruit ambiant de la supply chain. Lorsque vous combinez la prévision probabiliste avec l’optimisation stochastique, vous éliminez en grande partie tout besoin d’intervention manuelle. Et quand je dis « en grande partie », je veux dire que pour la plupart des clients, cela élimine complètement ce besoin. Il nous reste alors des tâches nécessitant de passer par du texte pour procéder, et c’est là qu’interviennent les LLMs. De plus, ce que je viens de décrire correspond à Lokad, nous avons ces AI Pilots qui sont réellement automatisés et, s’il y a une intervention manuelle, ce n’est pas pour effectuer une saisie administrative dans le système, mais pour introduire une révision stratégique de la recette numérique qui sera généralement une modification profonde de la logique elle-même afin de refléter la stratégie révisée. Ce ne sera pas, vous savez, une chose mineure. Ce sera typiquement quelque chose de fondamental qui modifiera la structure même de la logique mise en œuvre.
Conor Doherty: Celle-ci vient d’Ahsan. Pourriez-vous expliquer comment l’IA, spécifiquement, accélérerait une commande ? Serait-elle capable d’exécuter des transactions dans le système ERP sur la base de commandes verbales ?
Joannes Vermorel: Les commandes vocales ne constituent pas la bonne approche pour ce problème. Si ce que vous souhaitez, ce sont des saisies de données plus rapides, la voix est un canal à très faible bande passante. Vous tapez plus vite que vous ne parlez, à moins que vous ne soyez très mauvais en dactylographie. Ce n’est donc pas ce type de gain que vous pouvez obtenir. Si votre interface utilisateur est correctement conçue avec un clavier, vous serez plus rapide que par commande vocale. Je le sais très bien, car il y a 20 ans, je travaillais chez AT&T Labs à la pointe des systèmes de reconnaissance vocale de qualité industrielle. Il y avait une multitude d’applications où cela ne fonctionnait pas. La reconnaissance vocale fonctionnait, mais la réalité est que vos mains sur le clavier étaient tout simplement plus rapides. Les situations d’utilisation de la voix étaient soit quand les mains étaient sales, soit quand elles étaient occupées. Sinon, le clavier reste plus rapide.
Pour revenir à la question, il faut d’abord filtrer les commandes. Ici, nous avons un processus de prise de décision où vous devez déterminer quelles commandes doivent être accélérées. C’est du pur Lokad, un processus de prise de décision purement quantitatif. Vous devez décider, oui ou non, si cette commande en cours justifie une demande d’accélération du processus. Nous ferions cela avec le differentiable programming et l’optimisation stochastique. C’est ainsi que nous parvenons aux bonnes décisions.
Une fois cela établi, nous disposons automatiquement, chaque jour, des décisions concernant les commandes. Il ne s’agit pas d’avoir quelqu’un qui donne des ordres verbaux pour cela. Cela fera partie de l’ensemble des recettes numériques avec lesquelles nous allons calculer les commandes optimisées. Au fil du temps, nous constatons que certaines commandes dépassent ou restent en deçà des prévisions, et nous demanderons respectivement de reporter ou d’accélérer. La partie des LLM consiste simplement à utiliser cette décision quantitative, où vous avez une sorte de drapeau binaire indiquant “please expedite”, pour générer un email avec un contexte approprié, l’envoyer au fournisseur avec une formule du type “please acknowledge that you can do”, puis que le fournisseur accuse réception, en espérant qu’il dira “oui”, “non”, “peut-être” ou “voici ce que je peux offrir”.
Les LLM automatiseront le chat avec le fournisseur. L’IA ne consiste pas à décider d’accélérer la commande. Il s’agit d’une décision purement quantitative qui doit être abordée avec des outils quantitatifs, le differentiable programming et l’optimisation stochastique. Les LLM sont là pour l’interaction avec le fournisseur, qui utilisera fréquemment un canal non structuré comme l’email.
Si vous pensez aux commandes vocales, cela ne fonctionnera pas. C’est bien trop lent. J’ai eu le privilège de travailler avec les équipes qui ont littéralement lancé sur le marché les premiers systèmes de reconnaissance vocale de qualité industrielle il y a 20 ans. Mais en fin de compte, vous n’utiliserez pas ces technologies d’IA pour cela. Les commandes vocales n’ont pas la bande passante nécessaire pour faire ce que vous souhaitez.
Conor Doherty: Sur une note connexe, lorsque nous parlons de stochastic optimization et de differentiable programming, nous disposons de ressources vidéo étendues sur ces sujets. Nous n’entrons pas dans les détails car ils font partie d’une série en trois parties (part 1, part 2 et part 3) sur le differentiable programming, mais nous ne les ignorons pas. Ils ont été traités, et j’invite aimablement les spectateurs désireux d’en savoir plus à consulter ces ressources pour ensuite assembler les éléments.
Dernière question, et elle vient d’Isaac. En tant que client actuellement en train d’apprendre Envision, je suis intéressé par ses capacités d’intégration, en particulier avec GitHub. Pourriez-vous discuter du potentiel d’Envision à supporter l’intégration avec GitHub, notamment pour des applications telles que l’explication de blocs de code en langage naturel ou l’identification des changements entre les versions ? Enfin, y a-t-il un projet d’introduction d’un Envision copilot dans un avenir proche ?
Joannes Vermorel: La réponse courte est oui, oui, et oui. Les délais varient considérablement en fonction des composants dont nous parlons. Concernant l’utilisation des LLMs pour créer essentiellement un copilot, comme le GitHub copilot, mais qui sera le Lokad copilot sur les codes Envision, nous y travaillons déjà. Ce qui est très intéressant, c’est qu’étant donné qu’il s’agit d’un DSL que nous contrôlons, nous avons un contrôle total sur les matériaux d’entraînement. C’est vraiment cool car cela signifie que, le jour où nous parviendrons à mettre ce LLM en production, à chaque changement de syntaxe, nous relancerons notre processus d’entraînement avec la syntaxe mise à jour et nous disposerons toujours d’un copilot qui vous fournira la syntaxe Envision à jour. Contrairement au GitHub copilot qui vous propose une syntaxe Python, C# ou Java.
Parce que, voyez-vous, Java existe depuis 25 ans, Python depuis plus de 30 ans, C# depuis environ 22 ans ou quelque chose du genre. Ainsi, chaque fois que vous demandez au compilateur de GitHub d’écrire du code pour vous, le problème est qu’il vous fournit une version semi-récente de ces langages, mais pas vraiment ultra récente. Et parfois, vous ne voulez pas la version récente, car votre environnement n’est pas aligné avec ces versions super récentes que vous ne supportez pas encore.
Nous travaillons sur toute une série de fonctionnalités super naturelles telles que “comment my code”, “explain my code”, “complete my code”. Nous réfléchissons également à de nombreuses actions de code étendues qui sont très spécifiques aux workflows que l’on retrouve chez Lokad. Par exemple, nous travaillons sur l’automatisation de la génération de tableaux de bord de la santé des données. C’est une tâche très typique.
Les tableaux de bord de la santé des données sont essentiellement des instruments qui vérifient que les données que nous ingérons sont saines. Et nous possédons de nombreuses astuces et un savoir-faire pour savoir quoi vérifier, car les problèmes que vous rencontrerez dans les données des ERPs sont en quelque sorte toujours les mêmes. Lorsque nous vérifions la conformité des données provenant d’un ERP, nous, Supply Chain Scientists, avons littéralement cultivé nos propres méthodes d’entraînement pour savoir quoi rechercher et nous disposons de nos propres recettes — je veux dire, des recettes humaines — pour déterminer ce qu’il faut implémenter, ce qu’il faut vérifier, et nous pourrions largement automatiser cela avec les LLMs. C’est donc quelque chose qui est en cours chez Lokad.
Nous travaillons sur un Lokad copilot. Pour rendre Envision plus convivial avec GitHub, nous avons déjà publié une extension Visual Studio Code open-source. Vous pouvez déjà mettre du code Envision dans un dépôt git. Il suffit de créer un fichier .nvn, de le valider, et c’est tout. Si vous souhaitez éditer le code avec un joli coloriage syntaxique, vous aurez besoin d’une extension Visual Studio Code. Si vous recherchez l’extension Visual Studio Code de Lokad pour Envision, il en existe une entièrement open source qui vous offrira le coloriage syntaxique.
À l’avenir, nous prévoyons d’exposer le code Envision contenu dans un compte Lokad sous forme de dépôt git. La manière dont le code Envision est stocké dans un compte Lokad est pratiquement la même que celle d’un dépôt git. Il est versionné de manière similaire. Il n’est pas organisé exactement comme git — là encore, je ne vais pas trop m’attarder sur les raisons techniques. Git est très agnostique par rapport au langage. Si vous ne traitez qu’un seul langage en particulier, vous pouvez être plus astucieux et faire toutes sortes de choses qui ne seraient pas possibles dans le cas général. Mais en fin de compte, le code Envision est entièrement versionné. Nous pourrions exposer un dépôt git qui vous permettrait d’exporter tout votre code d’un compte Lokad vers un dépôt git et, peut-être plus tard, dans l’autre sens pour obtenir une synchronisation bidirectionnelle. Git est un système décentralisé où chaque dépôt git est comme l’ensemble du système : vous disposez d’une copie complète, vous pouvez récupérer des modifications depuis un dépôt distant tout en envoyant vos propres modifications. Ainsi, à un moment donné, nous pourrions introduire — probablement d’abord l’exportation, puis l’importation —, mais cela prendra du temps. Nous n’en sommes pas encore là. Cela fait partie de la feuille de route, mais nous n’avons pas encore de calendrier à ce sujet.
Conor Doherty: Il convient de souligner que quelques personnes dans les commentaires ont mentionné qu’elles apprenaient Envision. Nous produisons une série de tutoriels réalisés en collaboration avec l’Université de Toronto et quelques autres sont en préparation. Il existe des ressources gratuites et nous pouvons fournir des réponses à ceux qui le souhaitent. Pour quiconque souhaite apprendre, nos Supply Chain Scientists déploient de grands efforts dans ces ateliers. Ils sont disponibles gratuitement sur notre site web.
Joannes Vermorel: Pour ceux qui ne souhaitent pas devenir eux-mêmes Supply Chain Scientists, Lokad peut fournir le Supply Chain Scientist dans le cadre de l’offre AI Pilot.
Conor Doherty: C’est toutes les questions, Joannes. Merci beaucoup pour votre temps et merci beaucoup d’avoir regardé. J’espère que cela vous a été utile et nous nous reverrons la prochaine fois.
