Les pilotes d'IA dans la Supply Chain - Ep 159

00:00:00 Introduction à l’interview
00:01:01 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 les décisions dans les systèmes
00:13:08 Éviter le problème d’hallucination en IA
00:16:11 Impact et retards dus au retard informatique
00:20:04 Comparaison des configurations d’Lokad et des autres fournisseurs
00:23:06 Discussion sur les hallucinations et les confabulations de LLM
00:30:38 Mettre l’accent sur les progrès plutôt que sur la perfection en IA
00:33:00 Récupération des informations manquantes et ETA des commandes
00:36:17 Tâches quantitatives et LLM dans la supply chain
00:38:28 Avenir des pilotes d’IA dans la supply chain
00:41:18 Valeur des conversations et automatisation des tâches à faible valeur ajoutée
00:44:57 Tirer parti des pilotes d’IA pour réduire le retard
00:49:00 Pilote d’IA vs copilote et scénario de confinement
00:53:36 Skepticisme à l’égard de l’IA conversationnelle et de l’analyse des processus
00:57:18 Comprendre la réalité commerciale et l’IA remplaçant les processus
01:00:12 Défis de la mise en open source d’Envision
01:06:21 Approche de l’IA face aux goulots d’étranglement et à la supply chain
01:09:17 Inefficacité des commandes verbales et automatisation des commandes
01:14:12 Le Supply Chain Scientist en tant que copilote pour l’IA Pilot
01:17:32 Vérification de la correction des données et automatisation des vérifications avec LLM
01:20:15 Rendre Envision compatible avec git
01:21:14 Ressources gratuites pour apprendre Envision

Résumé

Dans un dialogue entre le PDG de Lokad, Joannes Vermorel, et le responsable de la communication, Conor Doherty, ils discutent de l’impact de l’IA sur la gestion de la supply chain. Vermorel met en avant les avancées de l’IA et des modèles linguistiques de grande envergure, qui ont révolutionné l’automatisation des tâches. Il présente les pilotes d’IA, une offre de Lokad qui automatise la prise de décision et les tâches administratives, facilitée par le langage de programmation propriétaire d’Envision. Vermorel aborde également le potentiel de l’IA pour automatiser les tâches liées aux données maîtres et compare l’approche de Lokad à celle de ses concurrents. Il prédit que les pilotes d’IA deviendront la norme dans la gestion de la supply chain, entraînant ainsi des améliorations significatives de la productivité. La conversation se conclut par une session de questions-réponses.

Résumé étendu

Lors d’une récente conversation entre Conor Doherty, responsable de la communication chez Lokad, et Joannes Vermorel, PDG et fondateur de Lokad, les deux hommes ont exploré le rôle transformateur de l’intelligence artificielle (IA) dans la gestion de la supply chain. La discussion, qui fait suite à 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écision en matière de supply chain.

Vermorel a commencé par mettre en avant la réalisation historique de l’IA générative et des modèles linguistiques de grande envergure (LLM) en 2023. Ces avancées, a-t-il expliqué, ont révolutionné l’automatisation des tâches impliquant du texte, telles que la lecture des e-mails ou la catégorisation des plaintes. L’année 2023 a été particulièrement significative car elle a entraîné 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, avec les opérations de la supply chain en première ligne.

Vermorel a ensuite présenté les pilotes d’IA, une offre de Lokad qui automatise le processus de prise de décision et gère les tâches administratives fastidieuses. Il a souligné l’approche unique de Lokad, où un Supply Chain Scientist peut prendre en charge une initiative dans son intégralité. Cela est rendu possible grâce au langage de programmation propriétaire d’Envision, dédié à l’optimisation prédictive des supply chains. Cependant, Vermorel a admis que Lokad avait auparavant rencontré des difficultés pour trouver des données et traiter différents dialectes SQL.

L’introduction de GPT-4, a expliqué Vermorel, a été un véritable game-changer 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. Cette évolution, associée à une connexion sécurisée de cloud à cloud, permet à l’équipe de Supply Chain Scientists de Lokad de récupérer les données des clients par elle-même, réduisant ainsi les retards.

Vermorel a également souligné le potentiel des LLM pour automatiser de nombreuses tâches liées aux données maîtres, notamment l’enquête, la surveillance et l’amélioration. Il a comparé l’approche de Lokad à celle de ses concurrents, affirmant que Lokad implique généralement moins de personnes dans une initiative, chaque personne ayant des compétences sur l’ensemble du processus. Selon lui, cela contraste fortement avec les concurrents qui impliquent souvent beaucoup plus de personnes dans une initiative, y compris des chefs de projet, des consultants, des concepteurs UX, des administrateurs de bases de données, des spécialistes réseau 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 dans la bonne direction et peuvent être corrigés avec quelques itérations grâce à une boucle de rétroaction. Il a suggéré que bien que les LLM puissent faire des erreurs, ils peuvent néanmoins apporter beaucoup de valeur, et leur taux de faux positifs et de faux négatifs peut être mesuré.

Vermorel a ensuite expliqué l’orchestration quotidienne entre le Supply Chain Scientist, le pilote d’IA et le client. Le pilote d’IA, composé par le Supply Chain Scientist, gère les opérations quotidiennes de la supply chain, en gérant les détails de la préparation des données et des décisions de commande. Le client, dans cette configuration, est assimilé au capitaine, donnant des directives stratégiques globales.

En ce qui concerne les enseignements à tirer pour les praticiens de la supply chain et les équipes de direction, Vermorel a prédit qu’à l’avenir, les pilotes d’IA seront la norme en gestion de la supply chain (SCM). Selon lui, cela entraînera 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 plus de temps à la réflexion stratégique et aux 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 à des questions sur divers sujets, notamment le rôle des pilotes d’IA dans la réduction du retard informatique, la différence entre un pilote d’IA et un copilote, l’importance de l’analyse des processus avant la mise en œuvre d’un modèle d’IA, les projets de Lokad pour rendre Envision open source et la manière dont l’IA résout les goulots d’étranglement aléatoires. Il a également confirmé que Lokad travaille sur un copilote Lokad et prévoit de rendre Envision plus convivial avec GitHub.

Transcription complète

Conor Doherty: Bienvenue à Lokad live. Je m’appelle Conor. Je suis responsable de la communication ici chez Lokad. Et je suis rejoint en studio par le fondateur de Lokad, Joannes Vermorel.

Le sujet d’aujourd’hui est la façon dont l’IA peut agir en tant que pilote autonome pour la prise de décision en matière de supply chain. N’hésitez pas à poser vos questions à tout moment dans le chat YouTube, et nous y répondrons dans environ 30 à 35 minutes.

Et avec cela, Joannes, les pilotes d’IA dans la supply chain me font penser que cette conversation est en grande partie une extension de celle que nous avons eue, je pense 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 par rapport à l’IA dans la supply chain.

Donc, avant d’entrer dans les détails des pilotes d’IA, pourriez-vous donner à ceux qui ne l’ont pas vu un résumé, juste un résumé exécutif, de notre point de vue sur les emplois traditionnels par rapport à l’IA dans la supply chain ?

Joannes Vermorel: Le résumé est qu’un jalon a été atteint pratiquement en 2023. Ce jalon est l’IA générative et plus spécifiquement, les grands modèles de langage (LLM). En termes de recherche pure, c’est simplement une continuation de presque quatre-cinq décennies d’amélioration continue de l’apprentissage automatique. Donc, si vous regardez cela d’un point de vue de la recherche, 2023 est simplement une année comme les autres avec une longue séquence de progrès. Et il y a eu des progrès relativement rapides au cours des deux dernières décennies.

Maintenant, en 2023, ce qui arrive sur le marché, c’est une IA générative emballée pour l’image et plus particulièrement pour le texte. Et il y a un produit qui a popularisé cela, c’est ChatGPT d’OpenAI. Qu’est-ce que cela signifie ? Cela signifie très spécifiquement, en particulier pour ces grands modèles de langage, que vous disposez d’une machine universelle de modélisation de bruit résiliente.

Cela signifie que toutes les étapes du logiciel d’entreprise, je parle dans le contexte des travailleurs comme s’il s’agissait de travailleurs de col blanc dans des environnements d’entreprise, cela signifie que toutes les étapes qui ne pouvaient pas être automatisées dans le passé parce que nous devions traiter du texte sous n’importe quelle forme, cela signifie lire un e-mail, extraire une référence ou un prix d’un e-mail ou une quantité ou catégoriser le type de plainte ou de demande d’un partenaire ou d’un client fournisseur à partir d’un e-mail, identifier si une étiquette de produit est absurde, par exemple, si la description du produit est manquante, d’accord nous avons un problème, toutes ces sortes de choses dans le passé ne pouvaient pas être faites facilement. Elles pouvaient être faites de différentes manières, mais elles ne pouvaient pas être facilement automatisées.

Si nous devions remonter disons cinq ans en arrière, la fouille de texte était déjà une chose. 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 a été un jalon parce que tous ces problèmes dus au degré d’emballage qui a été atteint avec essentiellement GPT-4 servi via une API, signifiait que tous ces techniques de traitement du langage naturel, avaient leur coût opérationnel pour les entreprises réduit d’un facteur de 100, voire de 1 000. Ce qui signifie non seulement le coût, mais aussi le délai nécessaire pour simplement mettre en place la chose.

Donc, en résumé, et c’est ma prédiction, de nombreuses fonctions de support dans les entreprises qui sont simplement des fonctions internes, qui prennent des données en entrée, produisent une sortie pour d’autres divisions, seront automatisées. La supply chain est en première ligne car ce n’est pas exactement une fonction orientée client. C’est une fonction très interne, importante, mais interne. Et donc les cas où les grands modèles de langage étaient la brique manquante pour automatiser largement 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écision quantitative depuis une décennie, mais il y a beaucoup d’opérations banales qui se produisent avant et après, et c’est celle qui peut être automatisée grâce aux grands modèles de langage, et rapidement et à moindre coût.

Conor Doherty: Eh bien, merci. Et nous avons déjà une vidéo où nous avons parlé pendant environ une heure et demie sur ce sujet, donc je ne consacrerai pas plus de temps aujourd’hui à cela, mais cela pose les bases pour le reste de la conversation. J’invite cordialement ceux qui veulent en savoir plus à consulter la vidéo précédente. Maintenant, à ce sujet, les pilotes d’IA, comment s’intègrent-ils à tout ce que vous venez de dire ? Qu’est-ce qu’ils sont ? Que font-ils en réalité ?

Joannes Vermorel: L’IA est généralement utilisée depuis deux décennies par les fournisseurs comme un terme générique pour regrouper ce qu’ils avaient. Donc, lorsque je parle des pilotes d’IA, c’est très clairement une offre de Lokad. C’est une évolution de l’offre, c’est probablement la plus grande que nous ayons eue depuis des années. Et quelle est la différence ? Eh bien, la différence est qu’un pilote d’IA est quelque chose, c’est un logiciel, ce que nous appelons une série de recettes numériques, qui non seulement exécute le processus de prise de décision, donc c’est l’aspect purement quantitatif de la supply chain, c’est-à-dire exactement combien commander, où allouer le stock, si vous devez augmenter ou diminuer les prix, comment planifier exactement la production avec toutes les étapes, etc.

C’est ce que nous faisions déjà, plus tout ce qui précède et suit en termes de tâches administratives banales qui sont principalement liées à la gestion des données de base avant l’analyse des données, puis à l’exécution de la décision qui peut impliquer des canaux non structurés comme les e-mails, par exemple, où vous voulez envoyer un e-mail à un fournisseur pour demander quelque chose à être accéléré ou, au contraire, à un ordre d’être reporté.

Et l’essentiel de cette offre, ce sont évidemment les grands modèles de langage que Lokad n’a pas inventés, que nous utilisons depuis plus de 14 mois, un peu plus que cela maintenant. Et l’idée clé de la façon dont Lokad fonctionne est qu’il devrait y avoir un Supply Chain Scientist qui est capable de prendre en charge pleinement une initiative.

Pour les très grandes entreprises, nous pouvons avoir plusieurs personnes sur le cas, mais contrairement à la plupart de nos concurrents, elles ne sont généralement pas spécialisées. Ce n’est pas comme si nous prenions une équipe de trois personnes avec M. Database, M. Algorithms et M. UI et UX user experience. Ce n’est absolument pas la façon dont Lokad fonctionne. Un Supply Chain Scientist est capable de tout faire de A à Z.

Et c’est l’une des raisons pour lesquelles Lokad a conçu sa propre technologie, sa propre technologie, 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 sembler très étrange d’avoir créé un langage de programmation sur mesure, mais l’idée principale est que nous, et c’est une décision que j’ai prise en 2012, nous avions vraiment besoin de quelque chose qui soit unifié pour qu’une seule personne puisse tout faire, de A à Z.

Jusqu’à il y a quelques années, cela consistait principalement à obtenir les données brutes de transaction à partir des ERP, des CRMs, de l’EDI et de tous ces systèmes transactionnels, à compléter cela avec une série de feuilles de calcul pour toutes les données structurées qui font malheureusement partie de l’IT de l’ombre plutôt que de l’IT régulier, puis à élaborer les recettes numériques de prise de décision. Et c’était la responsabilité du Supply Chain Scientist de faire tout cela, puis de concevoir tous les instruments, y compris les tableaux de bord et les rapports, pour s’assurer de la justesse des chiffres, mais aussi pour rassurer nos propres clients sur la validité de ce que nous faisons, ainsi que tous les instruments pour surveiller la qualité des décisions dans le temps, ainsi que la plomberie pour extraire les données des systèmes mais aussi réinjecter les décisions dans les systèmes également.

C’était donc le périmètre que Lokad avait, et il y avait deux choses que nous ne pouvions pas vraiment faire. Tout d’abord, nous devions être le destinataire des données, nous ne pouvions pas vraiment chasser les données. Et quand je dis chasser, le Supply Chain Scientist pouvait demander les données, nous ne demandions pas aux divisions informatiques de nos propres clients de faire des transformations sophistiquées, il s’agissait simplement de déverser les tables, vous savez, select star from table, bam, vous faites cela une fois par jour et c’est terminé. Donc c’était juste des extraits super simples, mais c’était quand même l’IT de nos clients qui s’en chargeait.

Les Supply Chain Scientists n’étaient pas censés chercher dans le paysage applicatif de nos clients les données dont l’initiative avait besoin. La raison en était très simple, il existe environ une vingtaine de dialectes SQL, tels que Oracle SQL, Microsoft SQL Server T-SQL, MySQL, PostgreSQL, DB2 d’IBM, etc. Il y a donc une vingtaine de dialectes SQL. Jusqu’à il y a quelques années, un Supply Chain Scientist aurait eu énormément de difficultés, même si ce que cette personne voulait accomplir était extrêmement simple, comme déverser une seule table, le problème était que cette personne aurait passé littéralement des dizaines d’heures à chercher en ligne pour composer des requêtes triviales, et chaque fois qu’il y avait un message d’erreur, c’était encore cette personne, même si cette personne était généralement familière avec les bases de données SQL en général, c’était, je dirais, un obstacle énorme à surmonter avec des dialectes de systèmes que vous ne connaissiez pas.

En 2023, avec ChatGPT, le problème est résolu. ChatGPT, en tant qu’assistant programmeur, n’est pas naturellement super performant pour vous permettre de composer des applications sophistiquées, mais quand il s’agit de composer des requêtes SQL très simples dans des dizaines de dialectes, c’est super rapide. Un Supply Chain Scientist va demander à ce qu’une requête SQL soit composée. Cette personne est également intelligente et relira la requête pour s’assurer qu’elle reflète l’intention. Il s’agit simplement de supprimer 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 le tester vous-même, demandez simplement à ChatGPT de vous guider pour configurer git sur votre machine et mettre en place un dépôt git ou autre, vous verrez quel genre de réponse de très haute qualité vous pouvez obtenir.

C’est vraiment un changement de paradigme car cela signifie que soudainement, Lokad, qui forme des Supply Chain Scientists, peut prendre la responsabilité de chasser les données. Et je sais que nous avons, grâce à ChatGPT, les outils nécessaires pour ne pas nous engager à chercher les données. C’est un changement de paradigme. Au lieu de demander à l’informatique de nous envoyer les données, nous pouvons simplement avoir une adresse IP sur liste blanche, puis établir une connexion sécurisée de cloud à cloud, et laisser l’équipe de Supply Chain Scientists chercher leurs propres données.

Pourquoi cela fait-il une telle différence ? Eh bien, la réalité est que 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 de taille afin d’obtenir les 20 à 50 tables dont nous avons besoin. Il s’agit simplement de récupérer les tables, sans jointure ni filtrage complexe, c’est très simple. Le problème est que beaucoup de nos clients ont leurs propres divisions informatiques qui ont d’énormes arriérés. Je veux dire littéralement des années d’arriérés et lorsque vous avez trois ans d’arriéré, même si Lokad ne demande que 10 jours, ce sont 10 jours plus trois ans d’arriéré. Donc même si nous ne sommes pas exactement mis à la toute fin de la file d’attente, si nous sommes juste au milieu de la file d’attente, ces 10 jours de travail de l’informatique peuvent prendre environ un an à être réalisés et c’était, je dirais, une frustration que nous avions, c’est que la majorité des retards que nous rencontrions provenaient de l’informatique qui n’était pas incompétente ou lente, c’est juste qu’elle avait tellement d’arriéré qu’il était très difficile pour elle d’allouer ces 10 jours.

Donc ici, nous parlons de quelque chose où au lieu de demander 10, 20 jours de travail, nous parlons de quelque chose comme peut-être moins d’une journée de travail, quelque chose comme seulement quelques heures, juste pour ouvrir un accès très sécurisé et restreint aux quelques systèmes dont nous avons besoin. Et ensuite, les Supply Chain Scientists eux-mêmes vont surveiller les tables, mettre en place la logique d’extraction des données et s’assurer que les extractions de données sont vraiment, je dirais, légères.

La façon dont nous pouvons le faire est généralement en surveillant les performances. Chaque fois que les performances de la base de données diminuent, cela signifie qu’il y a beaucoup d’activité sur la base de données et donc vous voulez généralement soulager la pression et retarder votre propre processus de récupération des données. Parce que généralement, chez Lokad, nous avons besoin de rafraîchir les données quotidiennement, mais ce n’est pas super urgent. Je veux dire, encore une fois, 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 chaînes d’approvisionnement, si nous retardons la récupération de données de 30 minutes simplement parce qu’il y a une augmentation de l’activité sur cette base de données en ce moment, ce n’est pas un problème.

Le premier bloc d’engagement consiste à chasser les données nous-mêmes et ainsi éliminer la principale cause de retard et accélérer considérablement les initiatives. Encore une fois, ces retards devenaient très fréquemment la majeure partie du retard pour toute l’initiative Lokad pour passer en production, il suffisait d’attendre que l’informatique puisse allouer ces jours.

Le deuxième bloc d’engagement est l’amélioration des données maîtres. Et ici, encore une fois, dans le passé, lorsque vous êtes confronté à un catalogue où il y a, disons, 100 000 descriptions de produits, certaines d’entre elles sont des déchets, vous savez, peut-être 1%. C’est beaucoup de travail de passer en revue ces 100 000 références, d’identifier les descriptions ou les étiquettes de produits incorrectes, parfois il peut s’agir simplement d’un prix complètement incohérent avec la description. Si cela dit une vis et que le prix est de 20 000 dollars, ce n’est probablement pas juste une vis, c’est probablement autre chose, etc. Il y avait beaucoup de vérifications de base où cela semblait évident et simple, mais il était très difficile d’automatiser cela et il n’y avait souvent pas d’autre alternative que de faire examiner les entrées par une personne pour rechercher les éléments vraiment mauvais.

Avec un LLM, et éventuellement un LLM capable de traiter également des images, vous pouvez faire beaucoup de choses en ce qui concerne l’observation, la surveillance et l’amélioration de tout ce qui est lié aux données maîtres. Dans le cas spécifique de Lokad, la partie Données Maîtres nécessaire pour piloter les chaînes d’approvisionnement.

Conor Doherty: Eh bien, il y a beaucoup de choses là-dedans, merci. J’ai beaucoup de questions auxquelles je veux donner suite. Je vais faire un léger pas en arrière, car si je peux résumer tout cela, vous décrivez, et corrigez-moi si je me trompe, un Supply Chain Scientist avec accès à un bon LLM, peut accomplir un travail considérable. Un travail qui, jusqu’à présent, aurait pris beaucoup de temps et impliqué de nombreuses personnes. Maintenant, dans une configuration non-Lokad, combien de personnes supplémentaires seraient impliquées ? Combien de personnes seraient concernées ? Et ensuite, vous pouvez parler de son efficacité, mais simplement en termes d’effectifs, quelle est la différence entre les Supply Chain Scientists avec LLM et, je ne sais pas, S&OP par exemple ?

Joannes Vermorel: Nos clients sont généralement stupéfaits du fait qu’une grande initiative ne nécessite que 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 les gens pendant un certain temps. Donc, en fin de compte, Lokad représente généralement 1% du début à la fin. Si nous avons plusieurs personnes, c’est encore pour avoir une redondance. Un jour, vous vous concentrez sur cette partie du pipeline et je fais cette autre partie du pipeline, et le lendemain, nous échangeons. Ce n’est pas comme si les personnes ne se spécialisaient pas, chaque personne possède une compétence sur l’ensemble du pipeline. Il y a quelques variations et certaines personnes ont une spécialité particulière, mais dans l’ensemble, les personnes peuvent vraiment se substituer les unes aux autres.

Nos concurrents, c’est très différent. Même une petite initiative implique littéralement une demi-douzaine de personnes. Vous aurez le chef de projet qui est là pour coordonner les autres gars, puis vous avez le consultant, le concepteur UX, le configurateur, l’administrateur de base de données, le spécialiste réseau, et éventuellement un programmeur, un ingénieur logiciel pour les personnalisations qui ne sont pas natives. Encore une fois, Lokad est une plateforme programmatique, la plupart de nos concurrents, leurs plateformes ne sont pas programmatiques. Donc, chaque fois que vous voulez avoir quelque chose qui ressemble à 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 parties manquantes. Donc, Lokad n’est vraiment pas comme ça. Je dirais que nos concurrents, par défaut, c’est une douzaine. Les initiatives S&OP peuvent impliquer plusieurs dizaines de personnes, mais ce ne sont pas nécessairement autant de compétences différentes, ce sont surtout des personnes de différents services et très fréquemment, ce n’est pas très axé sur l’informatique.

Donc, Lokad serait, quand je dis une personne contre une douzaine, je compare cela à nos concurrents qui vendent des systèmes de planification avancée ou des systèmes d’optimisation des stocks, ce genre de logiciel d’entreprise.

Conor Doherty: Merci. Et pour revenir à un autre point que vous avez mentionné au début lorsque vous avez parlé des scientifiques de la supply chain, vous avez donné l’exemple des différents dialectes SQL et ensuite le scientifique de la supply chain qui peut ou non maîtriser ce dialecte spécifique du client validerait ou surveillerait les scripts qui ont été générés automatiquement car les LLM peuvent parfois halluciner.

Eh bien, à ce sujet, les LLM hallucinent très souvent. Maintenant, encore une fois, cela s’améliore, mais vous pouvez demander à un LLM avec un morceau de texte, “Trouvez ce mot caché, pouvez-vous le voir ?” et il dira oui, eh bien il n’est pas là. Je sais qu’il n’est pas là, vous savez qu’il n’est pas là. Comment pouvez-vous assurer la sécurité et contrôler la qualité lorsque vous parlez de tirer parti des LLM de manière automatisée ?

Joannes Vermorel: Les hallucinations, ou les confabulations comme je préfère les appeler, se produisent vraiment lorsque vous utilisez le LLM comme une base de connaissances de tout. Si vous utilisez les LLM comme une base de connaissances de tout, alors cela se produit. Si vous demandez des articles médicaux et que vous dites : “Donnez-moi une liste d’articles sur cette pathologie”, il va vous donner quelque chose qui est globalement correct. Les auteurs existent fréquemment, ils ont publié, ils ont des choses qui étaient dans ce domaine, ils ont publié des articles qui étaient un peu dans la même veine mais pas tout à fait. C’est encore une fois, pensez-y comme si vous demandiez à un scientifique de se souvenir de choses au-dessus de sa tête.

C’est très difficile, vous diriez, et si vous dites que vous devez le faire, ils trouveraient probablement quelque chose qui est à moitié plausible avec les noms corrects des collègues ou des chercheurs, les titres semi-corrects, c’est le genre de choses. Donc, c’est une situation où vous obtenez des confabulations, mais vous le demandez un peu. Je veux dire, vous demandez aux LLM de se comporter comme une base de données de tout, donc c’est très difficile, vous allez avoir ce genre de problème.

Même chose avec les dialectes SQL, vous essayez ça et vous obtenez quelque chose, cette chose sera approximativement correcte. Si vous demandez : “Je veux lire une table”, il va faire un “select star from table” ceci et cela. Il ne va pas vous donner, quand vous demandez, disons avec GPT-4, quand vous demandez de lire une table, il ne va pas vous donner “drop table”. Il peut vous donner une syntaxe qui est légèrement inadéquate, donc vous testez votre requête SQL et vous avez un message d’erreur et vous faites une petite modification et ça marche. Mais vous voyez, c’est toujours globalement correct. Si vous demandez de lire la base de données, il ne va pas produire une commande qui supprime une table ou modifie les taux de permission de la base de données.

Même chose 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 le prix de cela ?” Si vous demandez à GPT, il peut dire probablement quelque chose comme 10 000 dollars. C’est juste une estimation. 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 tellement de compresseurs différents pour différentes situations.

Donc, en fin de compte, les confabulations ne se produisent pas au hasard. Il y a vraiment des types spécifiques de tâches où elles se produisent beaucoup plus fréquemment. Donc, je dirais que lorsque vous le demandez, lorsque vous utilisez le LLM comme une base de données de tout, il vaut mieux vérifier deux fois. Cela peut être extrêmement utile, cela vous donne, par exemple, pour les dialectes SQL, une indication sur le type de mots-clés que vous devriez utiliser, à quoi ressemble la syntaxe, et il peut faire une petite erreur, oublier une virgule ou quelque chose, mais avec quelques itérations, vous y arriverez. Surtout parce que lorsque vous avez la requête SQL, vous pouvez réellement la tester sur la base de données, vous verrez la sortie et vous validerez, donc vous avez une boucle de rétroaction instantanée pour valider cela.

Si vous voulez détecter, disons, des étiquettes de produits étranges, des étiquettes de produits qui semblent suspectes comme cette description de produit manquante, c’est votre étiquette de produit, d’accord, c’est évidemment faux. Mais vous pouvez avoir toutes sortes de fausses informations. Par exemple, vous pouvez avoir une étiquette de produit qui dit “tournevis cruciforme”, c’est en français et donc le problème est que c’est juste en français, c’est un tournevis avec une tête Phillips je pense. Et donc encore une fois, vous pouvez demander des choses mais à un moment donné, ce n’est pas parfait, c’est un jugement. Un humain ferait la même erreur, donc vous ne pouvez pas vous attendre à ce que le LLM soit un oracle final qui est capable de répondre à toutes les questions correctement. À un moment donné, si vous effectuez une tâche telle que la vérification des 100 000 produits de votre catalogue pour détecter des anomalies dans les étiquettes, le LLM aura des faux positifs et des faux négatifs comme un humain. Mais ce qui est intéressant, c’est que vous pouvez réellement 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 fréquemment, 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 : Le progrès, pas la perfection.

Joannes Vermorel : Exactement. Si vous pouvez réduire de 90 % vos problèmes de données maîtres avec quelque chose de très bon marché et qui peut être réexécuté en quelques heures sans surveillance, c’est très bien.

Conor Doherty : Il y a aussi la valeur du temps qui n’a pas été consacré à faire cela manuellement, vous auriez pu faire autre chose qui génère ou ajoute de la valeur. Donc, encore une fois, il y a des facteurs directs et indirects de valeur.

Joannes Vermorel : De plus, la réalité est que lorsque vous effectuez une tâche super répétitive pendant une heure, vous pouvez atteindre un certain niveau de qualité. Lorsque vous le faites pendant 100 heures, à l’heure 67, je veux dire, en général, les humains ne sont pas des moteurs de performance constants. Après quelques heures, la concentration baisserait et donc le nombre de faux positifs, de faux négatifs augmenterait probablement, même avec un employé assez diligent.

Conor Doherty : Merci. Et je tiens à être conscient du fait que nous avons en fait quelques questions de l’auditoire qui abordent des choses que j’allais demander, donc je vais sauter certaines choses mais elles seront abordées dans les questions de l’auditoire. Mais une dernière réflexion ici, lorsque vous parlez des Supply Chain Scientists, de l’AI Pilot, et nous reviendrons sur cela plus tard dans les questions, mais le Supply Chain Scientist, un AI Pilot et le client, comment cette orchestration fonctionne-t-elle réellement au quotidien ? Le client a-t-il accès, interagit-il avec le LLM ?

Joannes Vermorel : Typiquement, nous le voyons comme toutes les recettes numériques composées par les Supply Chain Scientists sont l’AI Pilot. C’est la chose qui pilote la supply chain au quotidien. C’est sans surveillance et cela génère les décisions. Maintenant, avec les LLM, il gère les détails de la préparation des données et les décisions PO également. Par exemple, la pré-décision consisterait à demander aux fournisseurs leurs MQS. Vous devez récupérer cette information, elle est manquante ou elle n’est pas à jour, vous devez la modifier. Les LLM peuvent vous aider à l’obtenir. La décision postérieure consisterait à envoyer un e-mail pour demander une ETA, une heure d’arrivée estimée, pour les commandes si vous n’avez pas de EDI en place ou si vous n’avez pas de pont, ou à demander d’accélérer une commande ou de la reporter. C’est le genre de détails qui vient ensuite où Lokad peut générer la décision de demander d’accélérer une commande mais ne pas effectuer les détails qui consistaient simplement à composer un e-mail et l’envoyer.

Tout cela est pratiquement l’AI Pilot et c’est la grande recette numérique qui effectue le processus de bout en bout. Tout cela est mis en œuvre par le Supply Chain Scientist. C’est donc une extension du champ d’action de Lokad. Le Supply Chain Scientist est le copilote en réalité. Et pensez vraiment à cela comme lorsque je dis pilote, je veux vraiment dire comme un pilote automatique dans un avion. Et d’ailleurs, de nos jours, les manœuvres les plus difficiles des avions sont effectuées en pilote automatique. Lorsque vous avez des aéroports très effrayants comme l’aéroport historique de Hong Kong, avec un nouveau qui est beaucoup plus facile, mais ils en ont un qui est littéralement au milieu de gratte-ciel, alors le pilote automatique pour ces manœuvres est obligatoire. Donc c’est fait, c’est la machine tout le temps, les gens ne font que surveiller.

Ici, le Supply Chain Scientist conçoit les recettes numériques et il est le copilote. Il décide, il fait pratiquement la navigation pour diriger les choses, puis il conçoit le plan et le plan de cours pour le pilote. Mais fondamentalement, le Supply Chain Scientist joue le rôle de copilote, il pense aux directions, il pense à l’avenir et il s’assure que le pilote peut fonctionner aussi en douceur que possible. Mais fondamentalement, toutes les ajustements à haute fréquence, c’est le pilote, pas le copilote. Et ensuite, le client serait 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 sur le fauteuil et donne des instructions très générales à l’équipage. Donc le client dans cette configuration donne la stratégie et les orientations générales. Ensuite, c’est le rôle du Supply Chain Scientist de les mettre en œuvre et le rôle du pilote est simplement d’exécuter tous les ajustements micro nécessaires ou toutes les décisions quotidiennes nécessaires pour la supply chain, puis d’exécuter la supply chain en elle-même.

Conor Doherty: Et cela s’ajoute également, encore une fois, pour être clair car nous n’en avons pas parlé, à toutes les tâches quantitatives automatisées qui sont déjà effectuées. Elles sont faites depuis des années. Donc au cas où quelqu’un écoute et pense, “Oh, eh bien, ce ne sont que des tâches qualitatives”, nous parlons de bout en bout. Oui, quantitatif comme la facturation des facteurs économiques, la génération d’allocation, les achats, la tarification, tout cela est déjà piloté par l’IA et automatisé.

Donc le Supply Chain Scientist supervise ces deux types de consoles, quantitatives et qualitatives.

Joannes Vermorel: Exactement. Et la raison pour laquelle Lokad a finalement commencé à adopter ce mot-clé IA, qui est un terme générique, c’est parce que nous ajoutons maintenant, nous lançons dans le mélange, des LLM. Nous avions déjà l’apprentissage automatique avec la programmation différentiable et l’optimisation stochastique, mais maintenant nous ajoutons les LLM par-dessus. Et donc c’est littéralement une boîte à outils très complète.

L’effet est littéralement pour les clients, des supply chains qui peuvent fonctionner sans surveillance pendant des semaines. Les gens sont surpris de voir combien de temps on peut réellement fonctionner sans surveillance avec ces facteurs économiques. La beauté de cela, c’est que vous n’avez pas besoin de faire des ajustements micro. Par exemple, les ajustements des prévisions sont pour la plupart de nos clients complètement inexistants. Et la plupart des autres ajustements sont également effectués automatiquement, comme l’introduction de nouveaux produits, la suppression des anciens produits, l’introduction de nouveaux fournisseurs et la suppression des fournisseurs non performants.

Donc tout cela est un peu la routine et lorsque les recettes sont correctement conçues, elles ne nécessitent déjà pas beaucoup d’interventions dans le passé. Mais avec ce pilote IA qui inclut les LLM, l’ajout d’un nouveau fournisseur dans le mélange, toutes ces sortes de choses peuvent nécessiter encore moins d’interventions manuelles qu’auparavant.

Conor Doherty: D’accord, Joannes, merci. Nous avons parlé pendant environ 40 minutes. Il y a des questions auxquelles nous devons répondre, donc je vais nous y amener maintenant. Mais avant cela, en guise de résumé ou de réflexion finale, encore une fois dans le contexte de la conversation beaucoup plus large que nous avons eue il y a un mois et maintenant que nous avons aujourd’hui, quelle est la conclusion pour le praticien de la supply chain et disons les équipes de direction qui supervisent le praticien de la supply chain moyen ? Quelle est l’action à entreprendre ou la leçon à retenir pour eux ?

Joannes Vermorel: Je crois qu’une décennie plus tard, cette vision des pilotes d’IA, peut-être sous un autre nom, sera la norme. Peut-être que ce sera la norme et que les gens diront simplement “supply chain” et non “pilotes d’IA pour la supply chain”. Et il sera évident que la supply chain est, vous avez ces pilotes d’IA. Tout comme lorsque vous dites un ordinateur, vous ne dites pas “j’ai un CPU, j’ai de la mémoire”, il est évident que vous avez un CPU dans votre ordinateur, donc vous ne le mentionnez même pas.

Mon point de vue est qu’une décennie plus tard, ces fonctions seront largement automatisées et Lokad, avec ces pilotes d’IA, propose un ensemble de solutions qui le font simplement avec un Supply Chain Scientist. Pour nos clients, cela signifie que la pratique de la supply chain change de nature. Cela signifie qu’ils ont ces pilotes d’IA qui peuvent libérer beaucoup de bande passante. Et nous libérions déjà la bande passante pour le processus de prise de décision ou le calcul complexe. Mais maintenant, nous libérons également le temps qui était consacré à la surveillance de la liste des SKUs, de la liste des fournisseurs, de la liste des clients, simplement pour maintenir les données maîtres correctes, propres et saines. Tout cela disparaît également et supprime tout besoin d’interventions manuelles qui étaient très fréquemment même pas vraiment quantitatives par nature. Vous deviez corriger une étiquette, corriger une entrée, supprimer un doublon ou quelque chose du genre. Tout cela, encore une fois, Lokad s’en occupera.

Donc, en fin de compte, 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 pour les tâches répétitives. La réalité est que vous avez maintenant plus de temps et vous pouvez réellement faire ce qui est beaucoup plus difficile à automatiser et je pense que cela ajoute plus de valeur. Il faut donc réfléchir attentivement à la stratégie, passer beaucoup plus de temps à réfléchir aux options, à ce que vous devriez explorer au lieu de perdre votre temps sur des feuilles de calcul.

Donc, passez beaucoup de temps à réfléchir longuement et sérieusement aux problèmes difficiles, puis parlez aux fournisseurs et aux clients et engagez une conversation approfondie afin de pouvoir organiser votre propre supply chain pour satisfaire votre fournisseur et ainsi il sera prêt à 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 à l’opposé où, “Oh les fournisseurs, je suis le client, ils doivent s’adapter à moi”. Mais si vous pouvez mieux accommoder vos fournisseurs, c’est un effort d’équipe et vous pouvez avoir plus de fiabilité et de meilleurs prix.

Et vous pouvez faire le même effort avec votre client car il devrait y avoir la même collaboration. Et encore une fois, cela nécessite beaucoup de discussions intelligentes et c’est le genre de choses qui vont au-delà de ce que ces LLM peuvent fournir de nos jours. Donc, je crois que chez Lokad, nous pouvons automatiser les tâches que nous n’aimons pas, les tâches sans valeur ajoutée et les tâches administratives ennuyeuses, et laisser les personnes se concentrer sur des tâches semi-stratégiques de haut niveau. Je dis semi-stratégiques car vous parlerez à un client à la fois, puis vous ferez la stratégie qui consiste à résumer tout cela, à créer une vision, puis à soutenir la direction de la supply chain afin qu’elle ait une stratégie très claire et bien fondée pour son entreprise.

Conor Doherty: Donc, encore une fois, prenons deux exemples pour conceptualiser cela, comme les décisions de bas niveau, passer par une feuille de calcul Excel en disant, “Oh, il est écrit en noir, cela doit être noir”, comme si vous corrigiez automatiquement cela, c’est trivial, c’est banal, cela ne vaut pas votre temps. “Devrais-je ouvrir un entrepôt à Hambourg ?” C’est stratégique.

Joannes Vermorel: Oui, c’est stratégique. De plus, le problème est qu’il y a tellement d’options. Vous pourriez dire un entrepôt, devrais-je acheter, devrais-je louer, quel type de contrats, quel est le degré de mécanisation, dois-je avoir un contrat pour l’équipement afin de pouvoir le rendre, devrais-je louer l’équipement ou non. Je veux dire qu’il y a des centaines de questions et très fréquemment, toutes ces questions, je veux dire encore une fois, lorsque les gens doivent consacrer 99% de leur bande passante mentale à des tâches administratives, ils n’ont plus de temps à consacrer à ces grandes questions.

Vous voyez, si j’appliquais la loi de Parkinson, les gens diraient, j’ai vu de nombreuses entreprises où si je devais calculer la somme totale des minutes passées sur quelque chose comme les classes ABC, cela représenterait chaque année des années-homme investies dans les classes ABC. Et quand il s’agit de décider pour un nouvel entrepôt, on parle de semaines de temps. Mais vous voyez le déséquilibre où les gens passent littéralement des années de temps humain pour quelque chose de complètement absurde comme les classes ABC. Et quand il s’agit d’un investissement de 50 millions d’euros pour ouvrir un entrepôt, cela représente littéralement des semaines de temps et puis bam, une décision est prise. Vous voyez, cela devrait être le contraire.

Conor Doherty: Très bien, merci pour cela. Sur cette note, je vais passer aux questions du public. Merci beaucoup. N’hésitez pas à les soumettre jusqu’à ce que je m’arrête en gros. Donc, Joannes, ceci vient de Massimo. Pourriez-vous expliquer comment les technologies de l’information peuvent tirer parti des pilotes d’IA pour réduire les arriérés et pourquoi vous pensez que cette approche devrait être proposée ?

Joannes Vermorel: Les pilotes d’IA ne visent pas à réduire les arriérés des technologies de l’information. Il s’agit de faire face au fait que les technologies de l’information ont des années d’arriérés. Donc, notre plan chez Lokad ne vise pas à réduire l’arriéré des technologies de l’information. Il nécessite de repenser les technologies de l’information de la même manière qu’Amazon l’a fait. Ce serait un autre épisode. Je dirais de chercher la note de 2002 de Jeff Bezos concernant les API chez Amazon. L’essentiel est que tous les départements d’une entreprise moderne ont besoin de tonnes d’outils logiciels. Chaque division - marketing, finance, comptabilité, supply chain, ventes - veut tous ces outils logiciels et tout cela retombe sur les épaules des technologies de l’information. Les technologies de l’information s’effondrent sous cette charge.

Donc, mon point est que chez Lokad, nous sommes des spécialistes de la supply chain. Nous n’allons pas nous occuper de tout ce qui concerne le marketing, les ventes, la comptabilité, etc. Ce que nous disons, c’est qu’avec les LLM, nous pouvons libérer les technologies de l’information de s’occuper de Lokad. L’essentiel est que nous passons de 10 à 20 jours de travail des technologies de l’information pour mettre en place l’initiative de la Supply Chain Quantitative, construire le pipeline, à seulement quelques heures. Donc, nous ne résolvons pas l’arriéré. Les technologies de l’information font ce qu’elles font. Elles peuvent également bénéficier des LLM, mais dans leur cas, les situations sont beaucoup plus diverses, beaucoup plus difficiles.

Donc, ma proposition n’est pas que les LLM peuvent réellement aider les technologies de l’information à réduire leurs arriérés. C’est juste une façon pour Lokad, dans ce cas spécifique, de dire : “Eh bien, au lieu d’ajouter 20 jours de plus à l’arriéré, nous ajoutons simplement environ quatre heures et c’est terminé.” C’est ainsi que nous faisons face à l’arriéré. Et plus généralement, la solution à ces années d’arriéré est que chaque division doit internaliser la plupart des outils logiciels. Vous voyez, les années d’arriéré sont dues au fait que les entreprises demandent trop aux technologies de l’information. Chaque division devrait avoir des pratiques numériques - marketing, ventes, comptabilité, etc. Vous ne devriez pas demander aux technologies de l’information de résoudre tous ces problèmes pour vous. Vous devriez avoir des experts numériques dans chaque domaine pour le faire. Et c’est exactement l’essence de cette note de 2002, si je ne confabule pas, de Jeff Bezos à son équipe. C’est une note très célèbre. Vous pouvez taper “note célèbre Bezos” car il disait, en substance : “Vous avez deux semaines pour avoir un plan permettant à chaque division d’exposer toutes vos données afin que nous n’ayons pas ce genre de cloisonnement et de jeux de pouvoir dans l’entreprise, chez Amazon.”

Et Bezos concluait : “Chaque responsable qui n’a pas de plan sur mon bureau dans deux semaines est viré ou quelque chose comme ça.”

Conor Doherty: D’accord, merci. Ce prochain commentaire, 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 prenez-la comme une question. C’est de Jesse. “Un Supply Chain Scientist plus un LLM ressemble toujours à un copilote. Alors encore une fois, distinguez les pilotes d’IA des copilotes.”

Joannes Vermorel: La raison pour laquelle nous disons que c’est un pilote, c’est parce que nous avons des clients où pendant des semaines, toutes les décisions sont générées puis exécutées sans surveillance. Et quand je dis sans surveillance, je le pense vraiment. Pendant les 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 travaillaient pas, payés par l’État car l’État accordait des subventions en Europe. Plusieurs États accordaient des subventions pour rester chez soi et ne pas travailler. Et donc, c’était la situation. Donc, nous avions cela et lorsque vous avez une supply chain qui fonctionne pratiquement sans surveillance pendant 14 mois, je l’appelle un pilote, pas 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 pilote.

Mais à l’époque, nous n’utilisions pas de LLM. Et c’était une situation où les données étaient propres et il n’y avait pas de besoin urgent d’améliorer cette gestion des données maîtresses. Et c’était un client qui avait une très grande maturité en termes d’intégration EDI et autres. Donc, les choses qui étaient nécessaires avant et après étaient très, très limitées.

Quoi qu’il en soit, revenons à la question du copilote. La plupart des concurrents de Lokad disent qu’ils font un copilote. Et en effet, la façon dont ils le font, c’est quelque chose de complètement différent. Lokad, le Supply Chain Scientist, utilise un langage de programmation. Donc, lorsque nous utilisons un LLM, c’est pour générer, pour nous aider à générer des morceaux de programme. C’est à cela que nous l’utilisons.

Donc, le LLM est utilisé pour générer essentiellement des morceaux de programmes qui peuvent être des dialectes SQL, qui peuvent être quelques autres choses. Et ensuite, nous concevons le pilote et ensuite le pilote s’exécute sans surveillance.

Nos concurrents, en particulier ceux qui disent qu’ils vont apporter une 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). Donc, ce qu’ils font, c’est qu’ils composent une invitation. Ils vont, c’est littéralement tous nos concurrents qui disent qu’ils font de l’IA avec LLM en ce moment dans l’espace de la supply chain. Ils composent, disons, une douzaine d’invitations adaptées à divers scénarios. Ensuite, après l’invitation, ils injectent des données récupérées de la base de données, vous savez, cela peut être des statistiques descriptives de base. Ils injecteraient donc quelques dizaines de chiffres, ventes moyennes de la semaine dernière, du mois dernier, de l’année dernière, ou autre, vous savez, des statistiques de base qui correspondent au scénario. Et ensuite, ils ajouteraient la requête supplémentaire de l’utilisateur et ensuite le LLM complétera la réponse.

Vous voyez, donc encore une fois, les LLM ne sont qu’une complétion de texte. Donc vous composez un texte et il le complète. Et la génération augmentée par récupération, la partie récupération consiste simplement à récupérer quelques chiffres de la base de données et ensuite à composer. Mais en fin de compte, bon, maintenant vous obtenez quelque chose où vous pouvez poser une question. Mais la réalité est que si vous n’êtes pas ignorant, vous pouvez lire les chiffres directement à l’écran. Il n’y a pas de magie. Donc, les LLM ne voient que les chiffres, tout comme vous pouvez les voir sur votre rapport. Fondamentalement, il ne peut répondre qu’aux questions qui peuvent être facilement répondues par un tableau de bord.

Donc oui, si vous n’êtes pas vraiment familier avec la définition de chaque chiffre, cela peut vous éclairer. Mais vous pouvez également avoir, c’est là que Lokad le fait, avoir une sorte de mémo qui vous donne une description en une phrase attachée à chaque tableau de bord, pour chaque chiffre présent sur le tableau de bord. Et cela fera exactement le même rôle, sans aucune IA impliquée.

Donc, en fin de compte, je suis très, très sceptique à l’égard de ces IA conversationnelles, de ces copilotes, car ce sont essentiellement des gadgets superposés à des systèmes existants qui n’ont jamais été conçus pour un quelconque système d’apprentissage automatique, même pas pour le classique apprentissage automatique, sans parler des LLM.

C’est pourquoi je dis, à ma connaissance, tous nos concurrents font des copilotes où ils ont essentiellement quelque chose qui est, disons, un chatbot qui se trouve au-dessus des tableaux de bord. Mais cela ne fait aucune automatisation. Cela ne vous permet pas d’automatiser un quelconque pilote IA. C’est, ouais, un gadget par-dessus un système hérité.

Conor Doherty: D’accord, merci. Je vais continuer. C’est de la part de Kyle. “Pouvez-vous discuter de l’importance de l’analyse des processus avant de mettre en place un modèle IA ?” Je vais le prendre dans un contexte de supply chain.

Joannes Vermorel: Aussi surprenant que cela puisse être, l’analyse des processus est très importante. Mais pas nécessairement de la manière dont les gens pensent. La réalité est que, surtout dans les chaînes d’approvisionnement, les entreprises ont eu quatre ou cinq décennies pour inventer beaucoup de processus fictifs. Et je dis “fictifs” intentionnellement. La chaîne d’approvisionnement est un jeu de bureaucratie. Elle a un noyau bureaucratique. Le jeu de la chaîne d’approvisionnement au cours des cinq dernières décennies a été un moyen d’organiser le travail car vous ne pouvez pas avoir une personne qui gère tous les SKUs, tous les entrepôts, tous les emplacements, tous les produits. Donc, vous devez diviser et conquérir le problème, répartir la charge de travail sur des dizaines, voire des centaines de personnes pour les grandes entreprises, très grandes entreprises.

Donc, vous vous retrouvez dans 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. Donc, vous voyez, ce sont des processus accidentels, pas des processus essentiels. Donc, je dirais oui, vous devez faire l’analyse des processus, mais attention, 90% des processus existants ne traitent pas le problème fondamental auquel votre chaîne d’approvisionnement est confrontée, mais des problèmes accidentels créés par le fait que vous avez besoin de beaucoup de personnes pour résoudre les 10% du problème qui doivent être traités.

Dans des industries comme le traitement chimique, où il y a beaucoup de flux et de dépendances, c’est très compliqué. Par exemple, lorsque vous avez des réactions chimiques, vous allez avoir des sous-produits. Donc, chaque fois que vous produisez un composé, vous produisez autre chose. Cette autre chose peut être vendue ou utilisée pour un autre processus. Vous devez coordonner tout cela. Vous avez des tonnes de contraintes, vous avez des processus qui fonctionnent par lots et des processus qui fonctionnent en continu. C’est très compliqué.

Mais la réalité est que la plupart des processus, au lieu de se concentrer sur la réalité physique du problème, le fait que, disons, dans une industrie de processus, vous avez des réactions chimiques qui ont des entrées et des sorties très spécifiques et tout cela est très, très 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 inverser les processus qui disparaîtront lorsque vous mettrez en place le pilote IA.

La chose intéressante, c’est que lorsque vous le faites à la manière du pilote IA, 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. Donc, tous ces problèmes de coordination qui étaient résolus par autant de processus disparaissent simplement.

Mon expérience est que 90% de ces processus vont simplement disparaître d’ici la fin. C’est pourquoi je dis qu’il est très important de garder un regard attentif sur la couche physique de base de votre supply chain, par opposition aux processus inventés qui sont là simplement pour coordonner de nombreuses équipes. Ces choses ne vont pas être améliorées, elles vont être remplacées par le pilote IA.

Conor Doherty: Merci. Et en fait, un exemple que vous avez mentionné dans cette réponse offre une bonne transition ici. Donc, d’un téléspectateur Durvesh, avez-vous prévu de rendre Envision open source pour une utilisation éducative ou pour les petites entreprises ? Et peut-il être programmé avec des règles pour bénéficier aux entreprises B2B comme les produits chimiques qui nécessitent une saisie manuelle approfondie ?

Joannes Vermorel: Oui, nous avons prévu de rendre Envision open source à un moment donné. Mais permettez-moi d’abord d’expliquer pourquoi. Dans ce monde des logiciels d’entreprise, nous avons une documentation publique pour Envision. La plupart de mes pairs ont des langages spécifiques au domaine (DSL), mais ils ne sont pas documentés publiquement. Dassault Systèmes a acheté une autre entreprise appelée Quintiq. À l’époque, cela venait avec un DSL, qui n’est pas documenté publiquement. Donc, il y a littéralement dans l’espace de la supply chain, d’autres entreprises qui ont un DSL et qui ne sont pas publiques. Chez Lokad, nous documentons tout publiquement et nous avons un environnement sandbox gratuit pour Envision. Nous avons même des ateliers gratuits disponibles pour que vous puissiez réellement enseigner ou apprendre Envision avec des exercices. Nous en faisons beaucoup plus.

Maintenant, en ce qui concerne la mise en open source d’un langage, cela fait partie du plan mais c’est trop tôt. Pourquoi ? Parce qu’Envision est encore en évolution rapide. Vous voyez, l’un des problèmes que vous avez lorsque vous mettez en open source un compilateur, le compilateur est un logiciel qui vous permet de compiler votre script en quelque chose qui s’exécute. Dès que vous mettez en open source votre compilateur, cela signifie que les gens vont faire fonctionner du code Envision, dans le cas de Lokad, dans la nature. Et Lokad perd la possibilité de mettre à niveau automatiquement ces scripts. La réalité est que, au cours de la dernière décennie, Lokad a modifié des centaines de fois le langage de programmation Envision. 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 manière spectaculaire. Vous pouvez jeter un coup d’œil à une syntaxe vestigiale qui n’existe plus dans Envision.

Et donc, comment gérons-nous ce changement constant de syntaxe ? Eh bien, chaque semaine chez Lokad, nous avons des versions hebdomadaires le mardi et ce que nous appliquons, ce sont des réécritures automatisées pour tous les scripts Envision qui sont utilisés sur les plateformes Lokad. C’est l’une des principales caractéristiques d’Envision, c’est d’avoir une très grande affinité pour l’analyse statique. Et l’analyse statique est, soit dit en passant, une branche de la conception et de l’analyse des langages. Lorsque je dis langage, je veux dire langage informatique, qui vous permet d’avoir 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 vers la nouvelle syntaxe. Et nous faisons cela automatiquement le mardi. Et généralement, lorsque nous effectuons une mise à niveau, nous aurons pendant quelques jours, nous aurons à la fois l’ancienne syntaxe et la nouvelle syntaxe qui sont acceptées. Nous effectuons les réécritures automatisées, puis lorsque nous constatons que l’ancienne syntaxe n’existe plus, nous verrouillons avec un indicateur de fonctionnalité 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. En général, nous le faisons comme une version chaque mardi, mais en général, nous avons environ deux réécritures par mois et nous faisons cela depuis une décennie. Tant que ce processus est en cours, Lokad ne peut pas réaliser une mise en open source réaliste d’Envision. Cela viendra en temps voulu, mais je ne veux pas répéter l’énorme erreur de Python. La mise à niveau de Python 2 vers Python 3 a pris à la communauté Python une décennie et c’était incroyablement douloureux. Je veux dire, les entreprises ont passé des années à effectuer des mises à niveau, c’était un cauchemar qui a duré une décennie. Donc c’était vraiment, vraiment une erreur. Même Microsoft avec la mise à niveau de C# du framework .NET à .NET Core a pris une demi-décennie et c’était une grosse, grosse douleur. Donc c’est, et c’est encore une fois le problème une fois que vous avez un compilateur qui est open source dans la nature, vous ne contrôlez pas le code. Donc si vous voulez apporter des modifications au langage, vous devez collaborer avec votre communauté. Cela rend le processus super lent, super douloureux et à la fin, vous n’éliminez jamais vraiment toutes les mauvaises fonctionnalités de votre langage.

Si nous regardons Python, la façon dont, par exemple, la programmation orientée objet a été introduite dans Python, la syntaxe, ah, c’est lourd. On sent vraiment que Python n’a pas été conçu en pensant à la programmation orientée objet. C’était un ajout ultérieur à la fin des années 90 et la syntaxe est un peu nulle et maintenant elle est là pour toujours. Et d’ailleurs, chaque langage a ça. En C#, vous avez le mot-clé volatile qui ne sert plus à rien. C++ est coincé pour toujours avec l’héritage multiple. C’était une erreur. Avoir l’héritage multiple, c’était une mauvaise décision de conception qui complique tout, etc. La seule façon de pouvoir éviter ces grosses erreurs, Lokad, nous avons fait beaucoup de grosses erreurs dans la conception d’Envision, mais nous les corrigeons après coup et nous sommes toujours en train de le faire, surtout lorsque de nouveaux paradigmes arrivent. Par exemple, la programmation différentiable était un nouveau grand paradigme et nous avons dû réinventer le langage lui-même pour accommoder ce paradigme.

Au fait, il y a une proposition majeure de Swift, proposée par Apple, pour faire de la programmation différentiable un citoyen de première classe dans Swift. Mais cela ne se produira probablement pas de sitôt. C’est une refonte majeure, majeure. Pour l’instant, le langage qui se rapproche le plus de la programmation différentiable en tant que citoyen de première classe serait Julia et même là, il y a beaucoup de rustines.

Conor Doherty: Merci encore. Il en reste encore trois à traiter. Le prochain vient de Victor. C’est largement à propos de l’IA. Comment l’IA aborde-t-elle les goulots d’étranglement aléatoires étant donné qu’elle fonctionne sur de grands ensembles de données pour prédire des scénarios plausibles ou des problèmes récurrents ?

Joannes Vermorel: Soyons clairs, lorsque nous parlons d’IA, il s’agit d’une collection de techniques. Chez Lokad, nous avons généralement des LLM, de la programmation différentiable et de l’optimisation stochastique. La programmation différentiable est utilisée pour l’apprentissage, l’optimisation stochastique est utilisée pour optimiser sous contraintes en présence d’incertitude, le modèle probabiliste qui est généralement régressé avec la programmation différentiable, et les LLM sont utilisés pour créer ce moteur de modélisation universel et résistant au bruit.

Lorsque vous abordez la chaîne d’approvisionnement avec des outils probabilistes, la plupart des tâches suggérées par cette question disparaissent simplement. C’est la beauté des prévisions probabilistes, ces prévisions ne sont pas plus précises, elles sont simplement beaucoup plus résilientes au bruit ambiant de la chaîne d’approvisionnement. Lorsque vous couplez la prévision probabiliste à l’optimisation stochastique, vous éliminez largement le besoin d’intervention manuelle. Et lorsque je dis largement, je veux dire que pour la plupart des clients, cela l’élimine complètement. Et maintenant, il nous reste des tâches qui nécessitent de passer par du texte et de traiter cela, et c’est là que les LLM entrent en jeu. Et encore une fois, ce que j’ai décrit, c’est Lokad, nous avons ces pilotes d’IA qui sont vraiment automatisés et s’il y a une intervention manuelle, ce n’est pas pour effectuer une saisie administrative dans le système, c’est pour entrer une révision stratégique de la recette numérique qui sera généralement une modification profonde de la logique elle-même pour refléter la stratégie révisée. Ce ne sera pas, vous savez, une petite chose. Ce sera généralement quelque chose de fondamental qui change la structure même de la logique qui a été mise en œuvre.

Conor Doherty: Celui-ci vient d’Ahsan. Pourriez-vous expliquer comment l’IA, plus précisément, 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 verbales ne sont pas la bonne approche pour ce problème. Si ce que vous voulez, 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 d’être très mauvais en dactylographie. Donc, ce n’est pas le genre de gain que vous pouvez obtenir. Si votre interface utilisateur est correctement conçue avec un clavier, vous serez plus rapide qu’avec une commande vocale. Je le sais très bien car il y a 20 ans, je travaillais chez AT&T Labs sur les systèmes de reconnaissance vocale de qualité industrielle. Il y avait des tonnes d’applications où cela ne fonctionnait pas. La reconnaissance vocale fonctionnait, mais en réalité, vos mains sur le clavier étaient tout simplement plus rapides. Les situations où la voix était utilisée étaient soit des mains sales, soit des mains occupées. Sinon, le clavier est tout simplement plus rapide.

Revenons à la question, d’abord vous voulez filtrer les commandes. Ici, nous avons un processus de prise de décision où vous voulez décider quelles commandes doivent être accélérées. C’est du Lokad classique, c’est un processus de prise de décision purement quantitatif. Vous devez décider oui ou non, est-ce que cette commande en cours justifie une demande d’accélération du processus. Nous ferions cela avec la programmation différentiable, l’optimisation stochastique. C’est ainsi que nous parvenons aux bonnes décisions.

Une fois que nous avons cela, nous avons automatiquement chaque jour les décisions pour 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 que nous allons calculer pour les commandes optimisées. Au fur et à mesure que le temps passe, nous réalisons que certaines commandes dépassent ou ne sont pas suffisantes et nous demandons de les reporter ou de les accélérer respectivement. La partie du LLM consiste simplement à utiliser cette décision quantitative, où vous avez un indicateur binaire qui dit “veuillez accélérer”, pour générer un e-mail avec un contexte approprié, l’envoyer au fournisseur avec quelque chose comme “veuillez confirmer que vous pouvez le faire”, et ensuite le fournisseur va idéalement confirmer et dire “oui”, “non”, “peut-être que je peux” ou “voici ce que je peux offrir”.

Le LLM automatisera le chat avec le fournisseur. L’IA ne consiste pas à décider d’accélérer la commande. C’est une décision purement quantitative qui doit être abordée avec des outils quantitatifs, la programmation différentiable, l’optimisation stochastique. Le LLM est là pour l’interaction avec le fournisseur, qui va souvent utiliser un canal non structuré comme l’e-mail.

Si vous pensez aux commandes vocales, cela ne fonctionnera pas. C’est beaucoup 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 voulez faire.

Conor Doherty: À ce sujet, lorsque nous parlons d’optimisation stochastique et de programmation différentiable, nous disposons de nombreuses ressources vidéo sur ces sujets. Nous ne les détaillons pas ici car il s’agit d’une série en trois parties (partie 1, partie 2 et partie 3) sur la programmation différentiable, mais nous ne les ignorons pas. Ils ont été traités et je vous invite aimablement à consulter ces ressources pour en savoir plus, puis à assembler ces éléments.

Dernière question, elle vient d’Isaac. En tant que client qui apprend actuellement Envision, je m’intéresse à ses capacités d’intégration, notamment avec GitHub. Pourriez-vous parler du potentiel d’Envision à prendre en charge l’intégration avec GitHub, en particulier 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 des projets visant à introduire un copilote Envision dans un avenir proche ?

Joannes Vermorel: La réponse courte est oui, oui et oui. Les délais varient beaucoup en fonction des composants dont nous parlons. En ce qui concerne l’utilisation de LLM pour faire essentiellement un copilote, comme le copilote GitHub, mais qui sera le copilote Lokad sur les codes Envision, nous travaillons déjà là-dessus. La chose très intéressante, c’est que du fait que c’est un DSL que nous contrôlons, nous avons un contrôle total sur les supports de formation. C’est très cool parce que cela signifie que le jour où nous réussirons à mettre ce LLM en production, chaque fois que nous changerons la syntaxe, nous relancerons notre processus de formation avec la syntaxe mise à jour et nous aurons toujours un copilote qui vous donnera la syntaxe Envision à jour. Contrairement au copilote GitHub qui vous donne une syntaxe Python, une syntaxe C#, une syntaxe Java.

Parce que vous voyez, encore une fois, Java existe depuis 25 ans, Python existe depuis plus de 30 ans, C# existe depuis 22 ans ou quelque chose comme ça. Donc, lorsque vous demandez au compilateur GitHub d’écrire du code pour vous, le problème est qu’il vous donne une version semi-récente de ces langages, mais pas réellement super récente. Et parfois, vous ne voulez pas de la version récente car votre environnement n’est pas en phase avec ces versions super récentes que vous ne prenez pas encore en charge.

Nous travaillons sur toute une série de fonctionnalités très naturelles telles que commenter mon code, expliquer mon code, compléter mon code. Nous réfléchissons également à de nombreuses actions de code étendues qui sont très spécifiques aux flux de travail qui se produisent au sein de Lokad. Par exemple, nous travaillons sur la possibilité d’automatiser la génération de tableaux de bord de santé des données. C’est une tâche très courante.

Les tableaux de bord de santé des données sont essentiellement des instruments qui vérifient que les données que nous ingérons sont saines. Et nous avons beaucoup de trucs et de savoir-faire sur ce qu’il faut vérifier car les problèmes que vous trouverez dans les données des ERP sont toujours un peu les mêmes. Lorsque nous vérifions la correction des données provenant d’un ERP, nous, les scientifiques de la supply chain, avons cultivé, littéralement, nos propres méthodes de formation pour savoir quoi rechercher et nous avons nos propres recettes, je veux dire des recettes humaines, de ce que je devrais implémenter, ce que je devrais vérifier, et nous pourrions largement automatiser cela avec les LLM. C’est donc quelque chose qui est en cours chez Lokad.

Nous travaillons sur un copilote Lokad. Pour rendre Envision plus convivial avec GitHub, nous avons déjà publié une extension open-source pour Visual Studio Code. Vous pouvez déjà mettre du code Envision dans un référentiel git. Il vous suffit de créer un fichier .nvn, de le valider et c’est terminé. Si vous souhaitez modifier le code avec une coloration de code agréable, vous aurez besoin d’une extension Visual Studio Code. Si vous recherchez une extension Visual Studio Code Lokad pour Envision, il en existe une qui est entièrement open source et vous obtiendrez une coloration de code.

À l’avenir, nous prévoyons d’exposer le code Envision qui se trouve dans un compte Lokad en tant que référentiel git. La façon dont le code Envision est stocké dans un compte Lokad est à peu près la même qu’un référentiel git. Il est versionné de la même manière. Il n’est pas organisé exactement de la même manière que git, encore une fois je ne vais pas entrer dans les détails techniques. Git est très agnostique par rapport au langage. Si vous ne traitez qu’avec un seul langage en particulier, vous pouvez être plus intelligent et faire toutes sortes de choses qui ne sont pas possibles dans le cas général. Mais en fin de compte, le code Envision est entièrement versionné. Nous pourrions exposer un référentiel git qui vous permet d’exporter tout votre code à partir d’un compte Lokad vers un référentiel git et peut-être plus tard dans l’autre sens pour avoir une synchronisation bidirectionnelle. Git est un système décentralisé où chaque référentiel git est comme une entité complète, vous avez une copie complète et vous pouvez donc obtenir des modifications à partir d’un référentiel distant mais envoyer vos modifications à un référentiel distant. Et donc à un moment donné, nous pourrions introduire, nous introduirons 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 pour cela.

Conor Doherty: Il convient de souligner que quelques personnes dans les commentaires ont déclaré qu’elles apprenaient Envision. Nous produisons une série de tutoriels en collaboration avec l’Université de Toronto et quelques autres qui sont en préparation. Il existe des ressources gratuites et nous pouvons fournir des réponses si les gens le souhaitent. Pour ceux qui veulent apprendre, nos scientifiques de la supply chain mettent beaucoup d’efforts dans ces ateliers. Ils sont disponibles gratuitement sur notre site web.

Joannes Vermorel: Pour ceux qui ne sont pas intéressés à devenir eux-mêmes des scientifiques de la supply chain, Lokad peut fournir le scientifique de la supply chain dans le cadre de l’offre AI Pilot.

Conor Doherty: Ce sont toutes les questions, Joannes. Merci beaucoup pour votre temps et merci beaucoup de nous avoir regardés. J’espère que cela a été utile et nous vous verrons la prochaine fois.