Exposé de Joannès Vermorel

Quelques mots de présentation avant d’entrer dans le cœur du sujet. Je dirige Lokad, ex-start-up, mais toujours française ! Je suis passé par l’École des mines, où j’ai fait deux ans de thèse en bio-informatique, avant de partir en 2008 dans une tout autre direction, celle de la supply chain. Lokad, qui n’a jamais effectué de levée de fonds et dont le développement a toujours été autofinancé, a mis plusieurs années avant de prendre son envol, mais elle connaît aujourd’hui une croissance de 30 % par an, dégage une très bonne rentabilité et emploie une cinquantaine de salariés.

Qu’est-ce que la supply chain ?

Avant de vous raconter l’aventure que fut et que continue d’être Lokad, permettez-moi de définir ce qu’est la supply chain : c’est la maîtrise de l’optionnalité en présence d’incertitude et dans un contexte de gestion de flux de biens physiques. Par optionnalité, il faut entendre prise de décisions – décider de passer commande à un fournisseur pour réapprovisionner un produit, de monter ou de baisser un prix, etc. Toutefois, maîtriser l’optionnalité, ce n’est pas seulement prendre des décisions de ce type à un instant T, c’est aussi faire en sorte de se créer un maximum d’options dans le futur, sachant que les décisions prises à l’instant présent conditionnent celles que l’on pourra ou que l’on ne pourra pas prendre à l’avenir. Trouver un fournisseur de rang 2 sur un produit donné, au cas où le fournisseur principal viendrait à faire défaut, en est un exemple. Le deuxième élément clef de la définition est l’incertitude. L’essence de la supply chain est d’être le liant qui colle ensemble les diverses entreprises ou les diverses entités d’une seule et même grande entreprise. Néanmoins, autant l’on peut légitimement aspirer à maîtriser ce qui se passe à l’intérieur d’une unique usine, autant il serait vain de prétendre le faire à l’échelle de toute une multinationale. Un bateau qui vient se mettre en travers d’un canal et y bloque le trafic, une épidémie soudaine qui entraîne la fermeture du plus grand port de Chine, un président américain qui érige une nouvelle barrière douanière sur les produits de ce pays sont des aléas dont la supply chain est fortement tributaire, mais qu’aucun supply chain scientist au monde, si doué soit-il, ne saurait anticiper, car ils sont par nature imprévisibles. Comme le montrent ces quelques exemples, l’incertitude peut prendre de multiples formes, la variabilité de la demande n’étant que l’une d’entre elles, parmi une dizaine d’autres. Le troisième et dernier pilier de ma définition est la notion de flux de biens physiques. C’est ce qui distingue le métier de la supply chain de celui de la finance de marché. Transformer des euros en biens physiques, lesquels se retransformeront à nouveau en euros, telle est la chaîne par laquelle passe nécessairement toute supply chain, mais la nature physique des biens, hormis aux deux extrémités de la chaîne, impose des contraintes que ne connaissent pas les activités intégralement financiarisées.

Ainsi défini, notre métier appelle quelques remarques complémentaires. La première est que toutes les grandes entreprises actives aujourd’hui ont digitalisé leur supply chain depuis la fin des années 1970 ; ce n’est donc plus à faire. C’est pourquoi un supply chain scientist de 2023 n’a pas vocation à digitaliser ce qui l’est déjà, mais à opérer sur la base des données existantes. Notre métier repose sur une couche transactionnelle – celle qui consiste, pour une entreprise, à enregistrer ses mouvements de stock, les commandes qu’elle a passées à ses fournisseurs, celles que ses propres clients lui ont passées, etc. – qui est en place depuis une quarantaine d’années. C’est au niveau de cette couche transactionnelle que l’on a vu émerger, dans les années 1990, les fameux ERP (Enterprise Resource Planning), qui n’ont de planification que le nom. Si ces représentations électroniques des flux physiques de la supply chain sont donc relativement anciennes, l’aspect optimisation prédictive – qui est au cœur de l’activité de Lokad – est, quant à lui, beaucoup plus récent.

La supply chain classique : des bases théoriques à reconstruire

Les limites de la théorie

Jusqu’à présent, je n’ai encore fait que vous tenir des propos avec lesquels je pense que tous mes concurrents tomberaient d’accord. Mais si vous voulez le fond de ma pensée, je vous dirais sans ambages que, de tout ce qu’on peut lire dans les manuels théoriques sur lesquels s’appuie la supply chain classique, rien, ou presque rien, ne fonctionne ! C’est d’ailleurs pour cette raison que Lokad a mis plusieurs années avant de vraiment décoller : comme tous ses concurrents, elle avait recours à des “recettes” qui ne marchent tout simplement pas, comme, par exemple, la prévision de la demande au moyen de séries temporelles. Les séries temporelles ne sont pas l’outil approprié pour prévoir la demande. Pour comprendre pourquoi, le plus simple est d’évoquer un cas concret, tiré de notre panel de clients : Rexel. Ce distributeur de matériel électrique peut être amené à répondre aussi bien à la demande d’un petit électricien qui va commander une poignée d’interrupteurs qu’à celle d’un chef de chantier ou d’un architecte qui va en commander plusieurs centaines. Or, en mélangeant ces deux types de flux l’un avec l’autre, les séries temporelles écrasent tout. Elles gomment toutes les nuances. Je pourrais multiplier à l’infini les exemples de ces pertes d’information qu’entraînent nécessairement les séries temporelles, en vous parlant des phénomènes de substitution/cannibalisation dans la mode, de l’importance critique de la marque pour certains produits particuliers (comme les couches-culottes pour bébés) dans les super- et hypermarchés, etc.

Je ne vais pas m’étendre davantage sur tout le mal que je pense de l’arsenal théorique sur lequel s’appuie la supply chain classique : les outils mathématiques ne sont pas les bons, ils ne permettent pas d’avoir cette vision claire et juste des forces en présence, sans laquelle l’optimisation prédictive est impossible. C’est ce que je n’avais pas encore compris durant les débuts de Lokad. Quand, en tant qu’ancien thésard de l’École des mines, j’ai voulu me lancer dans la supply chain, j’ai pris tous les manuels de référence – ceux du Massachusetts Institute of Technology (MIT), du California Institute of Technology (Caltech), de Yale… – et j’ai entrepris d’en coder les formules. Cela ne marchait pas, et pourtant mes clients étaient d’accord non seulement pour me payer, mais également pour recommander Lokad ! Comme si leur arrière-pensée était : « On a perdu pas mal de temps avec vous, la seule chose raisonnable à faire est de vous recommander chaudement à nos concurrents pour que vous leur fassiez perdre à leur tour autant de temps qu’à nous. » C’est ce qui explique que Lokad ait été (modestement) rentable dès le début, à l’époque où nous codions des formules qui ne donnaient aucun résultat probant. Nous tournions alors aux alentours de 500 000 euros de chiffres d’affaires, mais nos plus gros concurrents, dont le chiffre d’affaires pesait pour certains 1 milliard de dollars, faisaient exactement la même chose… Cela a duré jusqu’en 2012.

Le tournant de 2012

Le tournant s’est produit quand un distributeur bien implanté dans le Sud de l’Europe, et qui est devenu depuis un de nos clients, a soumis une demi-douzaine d’éditeurs de logiciels, pour les uns américains, pour les autres européens, à un benchmark. Il s’agissait de faire de la prévision de ventes à la maille SKU (Stock Keeping Unit, c’est-à-dire le niveau le plus désagrégé qui soit lorsque l’on traite de stock), à cinq jours, sur une dizaine de superettes alignant chacune quelque 5 000 références, avec comme critère d’erreur la différence entre les ventes prévues et les ventes réalisées (en valeur absolue). Ce jour-là, j’ai décidé, par défi, de mettre des zéros partout et j’ai obtenu le meilleur score, avec une confortable avance sur le deuxième ! Ma copie était statistiquement juste, mais complètement idiote. Si je raconte cette anecdote, c’est qu’elle fut pour moi à l’origine de ce que je pourrais appeler une véritable “crise de foi” : la profonde prise de conscience de l’absurdité de la supply chain classique, telle qu’elle est enseignée par les manuels.

Je me suis alors reposé un certain nombre de questions de base sur notre métier et il en a résulté que Lokad s’est mis à beaucoup mieux marcher. La première de ces questions fut : que cherche-t-on, in fine, à optimiser ? des pourcentages d’erreur ? non ! Ce que l’on veut réellement optimiser, c’est le profit ; et optimiser le profit signifie optimiser des euros d’erreur, non plus des pourcentages. La différence n’a l’air de rien, elle est pourtant fondamentale. C’est ce qui nous a amenés, chez Lokad, à développer des prévisions dites quantiles, dans lesquelles on peut introduire un biais que l’on choisit et contrôle – en l’occurrence, dans le cas de nos superettes, un biais pour le profit. Plus fondamentalement encore, cette prise de conscience m’a conduit à revisiter cette croyance toxique, héritée de la recherche opérationnelle, selon laquelle on sait par avance ce que l’on veut optimiser. On ne le sait pas. Comme dit plus haut, il faut raisonner en euros d’erreur, autrement dit financiariser le processus, mais on ne sait pas comment les compter, ces euros. Je vais illustrer ce point avec le cas d’un autre de nos clients. Si La Redoute décide de faire une démarque d’1 euro, sur l’un de ses produits, quel est le prix réel de cette démarque ? Il ne se réduit pas à cet unique euro de démarque, qui mécaniquement diminue d’autant la marge ; il englobe aussi le coût que représente, pour La Redoute, le cumul de cette remise dans le temps, sachant que, une fois cette démarque réalisée, elle induit une sorte de phénomène de cliquet dans les habitudes de consommation des clients et leurs attentes concernant les prix.

Rationaliser les systèmes complexes

Philosophie et pratique de l’optimisation expérimentale

Lorsque je dis qu’en réalité, et contrairement à ce qu’affirme à longueur de pages la recherche opérationnelle, on ne sait pas ce qu’on veut optimiser, il faut bien sûr entendre qu’on ne le sait pas d’avance ; cela ne veut pas dire qu’on ne peut pas le savoir, mais simplement que ce n’est pas donné d’emblée. Le rationalisme naïf, qui fait l’hypothèse que l’on sait dès le début ce que l’on cherche à optimiser, est une approche beaucoup trop grossière. Celle du supply chain scientist, telle que nous la mettons en pratique chez Lokad, s’appuie sur ce que nous appelons l’optimisation expérimentale.

Cette optimisation expérimentale est tout l’opposé du rationalisme naïf. Elle consiste à dire que, pour savoir ce que l’on veut optimiser, il faut d’abord générer une décision, puis laisser un ensemble de praticiens opposer à cette décision diverses objections, le plus souvent valables. C’est ainsi que nous travaillons. Notre supply chain scientist écrit tout d’abord une recette numérique, qui génère une décision. Nous laissons ensuite le soin aux gens du métier de nous pointer du doigt tous les endroits où cette décision se heurte violemment au réel. C’est pourquoi notre supply chain scientist passe son temps à jeter à la poubelle ses modélisations initiales. C’est un processus itératif, qui nous permet d’exposer massivement notre modélisation théorique au réel.

Là est le nœud de l’affaire. Les manuels du MIT ou autres sont immunisés face au réel. Leurs théories mathématiques présentent une forte cohérence interne, elles se tiennent, mais le réel leur demeure étranger. Nous voulons, au contraire, que nos modélisations aient été le plus possible exposées au réel avant de passer en production. Seule cette démarche d’optimisation expérimentale nous permet de savoir ce qu’il convient d’optimiser, de découvrir où se cachent les gains qui rendront possible l’optimisation financière. Il est très difficile, voire impossible, de le savoir a priori. Ma conviction, qui est aussi le credo de Lokad, est que lorsque l’on effectue cet effort de rationalisation, via une démarche d’optimisation expérimentale, il y a de très gros gains à la clef.

La chasse à la donnée pertinente

Un autre aspect du métier de supply chain scientist, tout aussi fondamental, est l’analyse des données. Ces dernières représentent le matériau brut sur lequel nous travaillons. Je trouve néanmoins que la vision que donnent les livres de ce qu’est la science des données est pour le moins fantaisiste. Adoptons le point de vue d’une entreprise lambda comptant 1 000 personnes et disposant d’un ERP qui ne comprend pas moins de 10 000 tables, chacune contenant 100 à 200 champs. Les ingénieurs à l’origine de cet ERP si foisonnant sont-ils encore dans l’entreprise, ou même encore en vie ? Pas forcément… Est-ce que la documentation qui accompagne le logiciel a un quelconque impact sur la façon dont les salariés l’utilisent ? Pas vraiment… Et cet ERP est loin d’être le seul logiciel utilisé par notre entreprise de 1 000 personnes. S’y ajoute en effet toute la palette des WMS, MRP, EDI, CRM et autres PLM – tous acronymes anglosaxons de trois lettres délicieusement obscurs –, sans oublier tous ces autres ERP, tous ces autres logiciels dont l’entreprise a hérité au fil de ses acquisitions ou fusions successives… Bref, c’est un bel enchevêtrement, un beau “plat de spaghettis” !

Face à cette situation, véritable chaos numérique, le rôle du data scientist devrait être non pas de faire de l’analyse ultrasophistiquée grâce aux derniers outils d’intelligence artificielle, mais, plus humblement et plus simplement, d’aider la direction de l’entreprise à retrouver ses petits. Une aide à la chasse à la donnée pertinente. Cela peut se faire, par exemple, en s’appuyant sur le concept d’entropie informationnelle de Shannon. Il est possible d’extrapoler ce concept à l’analyse des ERP, en regardant, colonne par colonne, combien chacune d’elles contient d’informations (au sens de Shannon). On constate alors que 60 % d’entre elles n’en contiennent que très peu, lesquelles sont d’ailleurs, pour la plupart, des erreurs. Ce n’est là qu’un exemple, parmi beaucoup d’autres, d’outil efficace pour faire émerger les zones d’information pertinentes.

Dans ce contexte, une grosse partie du travail du supply chain scientist consiste à documenter le logiciel à mesure qu’il progresse dans son décryptage des données. Au début, la documentation se réduit à une ligne par table ; à la fin, elle est d’une page par champ ! Cela explique que nous ayons besoin d’ingénieurs capables de travailler très vite et d’avoir une très grande souplesse intellectuelle, et que nous les recrutions donc dans les meilleures des grandes écoles. Nous avons besoin de gens très malins pour être capables de faire ce jeu de piste le plus vite possible.

La modélisation : un art tout d’exécution

Là-dessus se greffe la partie modélisation numérique, qui nécessite également de garder un peu de bon sens. Si vous observez une compétition Kaggle – nom de la plateforme web interactive de science des données de Google –, que voyez-vous ? Des geeks qui, sous prétexte de faire gagner 0,1 % sur un critère mathématique x, y ou z, vont monter des modèles d’une opacité totale, parfaitement intenables en production. C’est, à mon sens, l’inverse de ce qu’il faut faire. Lokad a participé à une compétition Kaggle de prévision de ventes organisée par Walmart. Nous sommes arrivés cinquièmes, sur plus de 1 000 compétiteurs, et pourtant notre modèle ne comportait que 5 paramètres. La communauté ne le jugeait pas sérieux, car trop simpliste, au point que nous avons eu du mal à le publier, mais cela ne l’a pas empêché de surclasser la grande majorité de ses concurrents au niveau mondial.

La maintenabilité en production du modèle est un enjeu crucial. Quand, en mars 2021, le porte-conteneurs de la compagnie Evergreen s’est retrouvé bloqué en travers du canal de Suez, nous avons eu des clients, comme La Redoute, qui nous ont appelés pour nous demander d’actualiser très rapidement notre modèle. Même chose lorsque se sont produites les inondations en Allemagne, durant l’été 2021 : beaucoup de nos clients avaient leurs entrepôts inondés et nous ont demandé de reconfigurer la supply chain. Être capable, de façon très réactive et rapide – par exemple en l’espace de vingt-quatre heures –, de tenir compte de ce genre de grosse “tuile” qui vous tombe dessus, me paraît plus important que d’aller chercher à n’importe quel prix le 0,1 % d’optimisation sur tel ou tel critère mathématique.

Pour résumer, je dirais que le supply chain scientist est un ingénieur qui a pour tâche de mettre de la rationalité dans des systèmes éminemment complexes ; pour ce faire, il a à sa disposition des outils qui sont des outils programmatiques, et le terrain de jeu que sont les données, souvent en quantité plus que suffisante – pas question de digitaliser davantage les supply chain existantes. Aller mettre de la rationalité dans des environnements aussi complexes et aussi “bruités” est un travail incroyablement difficile. C’est pour cela que je suis assez confiant dans le fait que les ChatGPT et autres LLM (Large Language Model) ne sont pas près de remplacer l’homme en ce domaine. C’est aussi un travail éminemment utile, constituant un puissant levier de rentabilité. Le supply chain scientist doit, à mes yeux, réussir ce que j’ai appelé le “Litmus test” : fait-il partie des quelques personnes occupant des postes clefs et par là même susceptibles à tout moment de recevoir un coup de fil furieux du directeur général au motif qu’une de ses décisions n’a pas été la bonne ? Si ce n’est pas le cas, cela veut dire que sa contribution est marginale. Mais je peux vous assurer que, chez les clients de Lokad, c’est bel et bien le cas…

Débat

Lokad, ses équipes et ses méthodes

Un intervenant : Pouvez-vous nous en dire un peu plus sur le modèle économique de Lokad ?

Joannès Vermorel : Nous facturons nos clients sur une base mensuelle. Cette facturation se décompose en deux parties : une partie plateforme, qui correspond à la puissance de calcul mobilisée et qui est bien évidemment proportionnée au volume de données, et une partie supply chain scientist(s), dont le nombre est lui aussi fonction de la complexité de la supply chain en question. Au total, la tarification peut varier de quelques milliers à plus de 100 000 euros par mois pour les chaînes logistiques de plus d’1 milliard d’euros que nous opérons au quotidien.

Int. : Comment travaillent vos supply chain scientists ? Vous nous avez expliqué qu’ils faisaient des hypothèses et attendaient que leur reviennent des objections, mais je ne vois pas bien comment un tel processus peut se dérouler lorsque des milliers de pièces sont en jeu…

J. V. : Quand des milliers, voire des centaines de milliers de pièces sont en jeu, nous faisons un échantillonnage. Prenons l’exemple de l’aéronautique : un avion nécessite l’assemblage d’une centaine de milliers de pièces différentes, mais comme la résolution d’un problème sur une pièce doit pouvoir s’étendre à un millier d’autres, il n’y a, en fin de compte, qu’une centaine de problèmes à résoudre. Nos supply chain scientists doivent être assez malins pour être capables d’effectuer ce travail de généralisation. J’ajoute que chacun de nos supply chain scientists porte, à titre individuel, la responsabilité de la recette numérique qu’il propose au client. C’est ainsi que se bâtit la confiance : on a face à soi une personne que l’on peut à tout moment questionner, “challenger”.

Int. : Si, comme vous nous l’avez dit, vos concurrents font de savants calculs qui ne servent à rien, mais se font payer quand même, comment avez-vous réussi à vous faire une place sur ce marché ?

J. V. : Je vais vous faire un aveu : Lokad perd à peu près tous les appels d’offres ! Néanmoins, je suis aujourd’hui capable de prévoir de façon assez précise au bout de combien de temps un concurrent ayant remporté un appel d’offres en viendra à présenter ses excuses – à défaut de résultats – à son client, et ce qu’il lui racontera pour se justifier… Ce calendrier du déroulé de l’échec est quasiment gravé dans le marbre. C’est pourquoi je peux aller voir une entreprise qui ne nous a pas retenu et lui dire : « Dans quatre ans, quand vous serez au désespoir, revenez nous voir ; alors, nous rediscuterons. » C’est ainsi que les entreprises, petit à petit, viennent à nous. C’est évidemment un processus assez lent – pour Rexel, nous avons mis une dizaine d’années avant de signer avec lui –, mais c’est ainsi. Une fois que les entreprises ont compris le mécanisme de l’échec, elles se laissent plus facilement séduire par Lokad, qui propose une solution sans engagement et à moindre coût.

Int. : Comment articulez-vous les différents services, lorsque vous avez affaire à des clients aussi tentaculaires que ceux de la grande distribution, par exemple ?

J. V. : Le plus difficile n’est pas tant d’articuler les différents services que d’arriver à briser les silos extrêmement rigides dans lesquels nos interlocuteurs sont enfermés. Dans la grande distribution, pour reprendre votre exemple, certains s’occupent de l’allocation des linéaires, d’autres de la gestion et de la prévision des stocks, d’autres encore des promotions, etc., et ces gens ne se parlent pas entre eux ! Nos supply chain scientists se retrouvent à devoir faire, passez-moi l’expression, la “tournée des popotes” auprès de tous ces gens coupés les uns des autres. Amazon, Zalando, ou encore Tesco disposent d’une ingénierie supply chain intégrée, mais elles ne représentent pas la majorité, loin de là ! Dans la plupart des cas, la collaboration des différents services prend la forme de réunions à n’en plus finir, dont il ne sort rien de bien opérationnel.

Int. : Ne pensez-vous pas qu’à force d’optimiser, il arrive un moment où il devient extrêmement difficile d’optimiser l’optimisation ? Et comment, alors, faire entendre ce message à vos clients ?

J. V. : C’est un vrai sujet. Nous nous heurtons, en effet, à du rendement décroissant. C’est pourquoi je dis et répète qu’une fois que nous tenons un bon modèle, il ne faut pas chercher à le suroptimiser. Souvent, à vouloir le suroptimiser, on ne fait que le rigidifier. C’est une discussion que nous avons souvent avec nos clients. Nous leur expliquons que le mieux est l’ennemi du bien, que toute optimisation supplémentaire ne serait que de l’optimisation de papier. Arrivé à un certain stade, mieux vaut se poser des questions orthogonales, remettre en cause les hypothèses implicites, par exemple : « Ne pourrais-je pas reconfigurer mon business avec des assortiments réduits ? » C’est ce qu’a fait Lego, quand cela se passait très mal pour elle, au début des années 2000. L’entreprise a alors restructuré sa supply chain et repensé ses boîtes, en divisant par deux le nombre de pièces différentes. C’est ce qui l’a sauvée, avec sa nouvelle politique de licences.

Int. : Le métier de vos supply chain scientists est très exigeant et engendre, je le suppose, beaucoup de stress. Combien de temps peut-on tenir à ce rythme ?

J. V. : Cette question du stress et du burn-out est cruciale. Dans les grands systèmes informatiques, c’est l’incendie permanent. Lorsque je dis que les modèles issus des compétitions Kaggle sont trop compliqués pour tenir en production, c’est bien pour cette raison : du fait même de leur complexité, ils produisent sans arrêt de nouveaux incendies ici ou là. Notre propre langage programmatique a été pensé et conçu sur le principe de la “correctness by design”, c’est-à-dire sa capacité à éliminer des classes entières d’erreurs, pour éviter de provoquer ces incendies qui engendrent du stress en production. La plupart des langages utilisés par nos concurrents sont conçus, au contraire, sur le principe de l’“expressivité maximale”, qui est à l’opposé de la correctness by design et qui me paraît relever d’un luxe superflu au regard de la nature des problèmes rencontrés en gestion de la supply chain. Par ailleurs, chez Lokad, nous avons introduit, de façon assez pionnière, la semaine de quatre jours, pour les salariés ayant déjà un peu d’ancienneté. Nos salariés tolèrent le stress jusqu’à leur premier enfant, mais ensuite, ils aspirent à souffler un peu, et la semaine de quatre jours est alors idéale pour eux. Cela les incite davantage à rester chez nous qu’une augmentation de salaire.

Nouveaux marchés, nouveaux horizons

Int. : À vous écouter, il m’a semblé que votre système pourrait parfaitement s’appliquer aux armées. Avez-vous commencé à avoir des expériences dans ce domaine ?

J. V. : Nous aimerions beaucoup ! Nous avons actuellement des discussions avec la gendarmerie française pour la gestion de leur stock de pièces détachées d’hélicoptères. Il se trouve qu’un de mes oncles était, jusqu’à une date récente, général. Les discussions que j’ai eues avec lui m’ont fait comprendre que l’armée raisonne en nombre d’opérations possibles ; son souci est de maximiser, à budget constant, le nombre d’opérations qu’il lui serait loisible d’exécuter. C’est un objectif non standard, qui nécessite une extrême agilité pour être capable de repenser la situation d’heure en heure, en fonction de l’évolution du contexte. Nous avons essayé de percer auprès du ministère de la Défense, mais, même si mon bras droit est polytechnicien et que les militaires sont extrêmement policés et agréables à fréquenter, cela reste très difficile de concrétiser rapidement quoi que ce soit avec eux. J’ajoute que je limite mes ambitions dans ce domaine à la France ; nous n’avons pas essayé de prospecter le complexe militaro-industriel américain, par exemple !

Int. : Justement, vous n’avez pas évoqué la présence de Lokad à l’étranger. Quelles sont vos ambitions et vos actions en la matière ?

J. V. : Nous avons un site web bien fourni, qui engendre du trafic, et il arrive régulièrement que des responsables d’entreprises étrangers, américains notamment, nous écrivent pour se renseigner sur Lokad et tenter l’aventure avec nous. Ce n’est pas un hasard si les États-Unis constituent notre premier marché. En effet, les Américains sont par nature assez “joueurs”, beaucoup plus que les Français. Ainsi, l’idée d’aller mettre quelques centaines de milliers de dollars dans une technologie qu’ils ne connaissent pas, mais qui pourrait marcher, ne les rebute pas, là où nos compatriotes se réfugient derrière des appels d’offres et des listes interminables de questions qui ne sont pas toujours pertinentes. Il est beaucoup plus difficile de gagner un nouveau compte en France qu’ailleurs. Air France fait aujourd’hui partie de nos clients, mais c’est en Allemagne, non chez nous, que nous avons initialement signé avec cette compagnie.

Int. : Connaissant le côté un peu frileux des Français en matière d’innovation, je ne m’étonne pas de ce que vous venez de dire. Pourquoi n’envisagez-vous donc pas, tout simplement, de vous installer aux États-Unis ?

J. V. : J’ai beaucoup de famille là-bas, dont une partie y a fait fortune, et j’ai moi-même travaillé près de deux ans dans ce pays. Je pense donc avoir une bonne idée du marché américain. J’arrive cependant très bien à vendre aux États-Unis depuis la France, et ce depuis le premier jour de Lokad : mes premiers clients étaient américains, pas français. En outre, le marché du travail dans notre pays étant ce qu’il est, avec un fort taux de chômage, nous y trouvons des ingénieurs extrêmement compétents à des prix très compétitifs. Le même niveau de compétences, aux États-Unis, se paye par des salaires exorbitants. Plutôt que d’aller nous implanter là-bas, nous préférons faire venir ici des anglophones, qu’ils soient originaires des États-Unis, d’Irlande ou d’Angleterre ; nous les recrutons même s’ils ne parlent pas notre langue – ce n’est pas un prérequis chez Lokad ! – et les mettons en première ligne pour prospecter le marché américain. Cela pose évidemment le problème des fuseaux horaires, mais, avec un petit bonus sur le salaire, on convainc facilement un nouvel élément d’avoir des horaires un peu décalés.

Int. : Vous avez évoqué le ministère de la Défense, mais je me désole du manque de vision, à l’échelle nationale et européenne, dans certains autres domaines stratégiques, comme celui des stocks de médicaments. Des modèles simples comme le vôtre, reposant sur un petit nombre de paramètres, ne pourraient-ils pas là aussi être employés à bon escient ?

J. V. : Dans ce secteur, la non-rationalité joue à plein, en effet ! La rationalité cède devant la peur. Souvenez-vous de la crise du papier-toilette que nous avons connue au début de l’épidémie de Covid-19. Un seul distributeur a eu alors le courage de mettre en place la seule réponse rationnelle possible : le premier pack à 4 euros, le deuxième à 50 euros. Problème résolu ! Qu’il s’agisse des médicaments ou des produits de première nécessité, la bonne réponse consiste souvent à trouver des leviers permettant d’agir sur le comportement des consommateurs.

Vraies et fausses révolutions technologiques

Int. : L’avalanche de nouvelles technologies – robotisation des entrepôts, intelligence artificielle… – joue-t-elle en faveur ou en défaveur d’une entreprise comme Lokad ?

J. V. : À la barre de Lokad, j’ai déjà traversé quatre révolutions technologiques. Le premier de ces moments de vertige, dès la création de l’entreprise en 2008, a été l’arrivée du cloud. Nous nous étions lancés avec des architectures clients-serveurs classiques et, tout à coup, le cloud a totalement changé la façon dont nous devions travailler. Nous avons dû complètement repenser notre technologie de l’époque pour opérer cette migration. Le deuxième moment de vertige a eu lieu quelques années plus tard, en 2013-2014, quand, à la suite de la publication d’un livre intitulé JavaScript: The Good Parts, le regard de la communauté sur ce langage de programmation a changé. Il est alors apparu aux yeux des spécialistes que, si l’on mettait de côté la majeure partie des fonctionnalités de JavaScript, il subsistait en lui un sous-ensemble utile ; nous étions partis pour centraliser tout le calcul dans le cloud, et il devenait désormais possible de le faire pour partie redescendre au niveau des postes clients. La troisième révolution a été celle du deep learning, qui a rendu le machine learning programmatique. Là encore, cela changeait tout ! Quant à la quatrième et dernière révolution en date, dans laquelle nous sommes actuellement plongés, c’est bien sûr celle des LLM. En 2012, nous avons décidé de créer notre propre langage de programmation, dédié à l’optimisation prédictive des supply chains. Il en résulte que, aujourd’hui, nos 30 supply chain scientists programment dans un langage que Lokad a lui-même développé. Or, il se trouve que cette dimension programmatique nous confère une excellente affinité avec le deep learning et les LLM. Si les LLM marchent désormais tellement bien, c’est qu’ils ont été pré-entraînés sur des bases de codes, avant même d’être confrontés au langage humain. C’est ce qui explique que ChatGPT et compagnie se révèlent si doués pour faire de la programmation automatique. Ils constituent ainsi un outil extraordinaire dans la main des éditeurs qui, comme Lokad, ont développé une approche programmatique. Nous entrevoyons d’innombrables applications possibles, et c’est pourquoi j’aborde ce quatrième gros virage technologique avec beaucoup d’enthousiasme !

Int. : J’ai entendu dire que Michelin mettait en place un jumeau numérique de sa supply chain, pour l’aider à faire face à des décisions telles que « faut-il ouvrir ou pas une usine en Chine ? », etc. Cette approche vous paraît-elle pertinente ?

J. V. : Non. Les jumeaux numériques me semblent relever, au contraire, du scientisme et du rationalisme le plus naïfs. Il est en effet naïf de croire qu’une simulation ou qu’un automate numérique va pouvoir répondre à notre place à toutes les questions qui se posent à nous, résoudre tous nos problèmes, comme s’il s’agissait de l’oracle ultime. Il ne peut en être ainsi, pour une raison facile à comprendre : faire une modélisation, c’est toujours, peu ou prou, tricher avec la réalité. On ne peut jamais intégrer dans un modèle tous les aspects du réel, il faut faire le deuil de dizaines de facteurs que l’on aimerait modéliser, mais que l’on ne modélise pas parce qu’ils rendraient le modèle ingérable. C’est pourquoi jamais un simulateur, si complexe soit-il, ne pourra être un bon outil prédictif. Michelin – ou tout aussi bien notre client Bridgestone –, lorsqu’il se confronte à la décision d’implanter ou non une nouvelle usine en Chine, ne doit pas envisager cette question sous le seul angle des chiffres ; ce serait faire preuve de myopie que de ne pas tenir compte, par exemple, du contexte géopolitique du moment. En tant que professionnel de la science des données, je regrette de constater que, trop souvent, les décideurs se sentent nus et frustres s’ils n’ont pas un chiffre pour justifier leur analyse ou leur décision. C’est l’une des facettes de ce que j’appelle le rationalisme naïf. Les recettes numériques ont l’avantage sur les humains lorsque les questions sont si nombreuses, si répétitives, qu’il est matériellement impossible de confier à ces derniers la tâche d’y répondre. Il ne faut mécaniser les réponses que dans les cas où l’on fait face, tous les jours, à des milliers de questions similaires. Or, Michelin ou Bridgestone ont beau être de très grandes entreprises, la question de savoir si elles doivent ou non construire une nouvelle usine en Chine ne se pose tout de même pas à elles des milliers de fois par jour… C’est un spécialiste des big data qui vous le dit : il y a des situations où la bonne réponse ne s’appuie pas sur les données quantitatives, mais doit être qualitative et argumentée. C’est cela, le vrai rationalisme.

Entre théorie et pratique

Int. : Vous nous avez dit que rien de ce que l’on pouvait trouver dans les manuels théoriques de supply chain ne fonctionnait. Quel discours tenez-vous à vos étudiants, en ce cas ?

J. V. : Je vais nuancer mon propos. J’ai vu des cours en ligne remarquables, sur la logistique urbaine notamment. On y recensait les forces en présence, on y exposait leurs intérêts contradictoires, on y expliquait que la solution relevait forcément du compromis. Cette présentation des choses me paraît bien plus conforme au vrai rationalisme que l’idée naïve de partir d’une situation pure et parfaite pour en dériver des applications concrètes. Mon message aux étudiants est : « Ne négligez pas l’anecdotique, ne pensez pas que l’on peut tout trivialiser à coup d’équations. » La sophistication ne réside pas toujours dans le modèle mathématique lui-même ; elle peut tout aussi bien consister à “détricoter” d’abord une situation complexe, puis, sur cette base, à construire une modélisation mathématique simple, qui répondra élégamment, avec une grande économie de moyens, au cahier des charges. La simplicité ne tombe jamais du ciel : pour aboutir à quelque chose de simple, il faut avoir énormément travaillé en amont.

Int. : Si je vous ai bien compris, la science académique a fait fausse route, du moins pour ce qui est de la supply chain… Le seul salut est-il dans le dialogue des chercheurs avec les praticiens ?

J. V. : Je pense que la grande erreur qu’a faite le monde académique en général, c’est la revue par les pairs. Cela crée une gigantesque chambre d’échos, qui stérilise la recherche. Le tout premier article scientifique que j’ai publié dans une revue à comité de lecture portait sur le problème du “bandit multi-bras”. Une étude ancienne, qui remontait aux années 1970, indiquait l’existence, pour ce problème, d’un algorithme optimal, nul n’étant censé pouvoir faire mieux que lui. Or, mon papier apportait la preuve du contraire ! En réalité, même des techniques naïves faisaient mieux que cet optimal supposé, mais personne ne s’en était rendu compte, car la recherche avait été stoppée par ce vieux résultat – incorrect ! – des années 1970. Cette situation a d’ailleurs fait que j’ai eu un mal fou à publier mon propre résultat, les spécialistes le rejetant au motif qu’il contredisait la science établie. Cela continue aujourd’hui. Depuis la création de Lokad, j’ai encadré cinq thèses, et les objections qui ont été opposées à mes thésards étaient pour la plupart affligeantes. Ce système de la revue par les pairs est profondément toxique. Il entretient les problèmes convenus.