Ressources informatiques en Supply Chain - Ep 167

00:00:00 Introduction aux ressources informatiques en supply chain
00:02:21 Importance des ressources informatiques en supply chain
00:07:04 Sympathie mécanique dans le contexte de la supply chain
00:09:38 Prise de décisions avec le matériel informatique
00:12:42 Illusion d’expertise sans profondeur
00:13:59 Dépendance moderne de la supply chain à l’informatique
00:18:32 Les impacts de la vitesse du matériel sur les décisions
00:21:40 Les inefficacités des logiciels augmentent les coûts
00:24:42 Propriétés et limitations des bases de données transactionnelles
00:27:59 La hausse des coûts du cloud computing due à l’inefficacité
00:30:09 Recettes logicielles plus simples et moins coûteuses
00:32:40 Gaspillage extrême des ressources informatiques
00:36:14 Avancées du matériel vs retard des logiciels
00:40:48 Importance de la connaissance de la sélection des fournisseurs
00:45:15 Connaissances théoriques vs pratiques
00:50:00 Ordres de grandeur dans l’efficacité informatique
00:54:33 Considérations de performance dans le réapprovisionnement des stocks
00:56:18 Processus itératif pour la qualité des résultats
00:58:50 La disruption nécessite une réingénierie
01:00:18 Prochaines étapes pour les praticiens
01:02:17 Payer pour les inefficacités des fournisseurs
01:05:04 Impact financier des décisions
01:07:16 Le manque de compréhension des concurrents
01:08:40 Remarques de clôture

Résumé

Dans un récent épisode de LokadTV, Conor Doherty, Responsable de la Communication chez Lokad, a conversé avec Joannes Vermorel, CEO de Lokad, au sujet du rôle crucial des ressources informatiques dans l’optimization de la supply chain. Vermorel a souligné la nécessité de comprendre à la fois le matériel et les logiciels pour prendre des décisions supply chain. Il a comparé ce savoir fondamental à une connaissance géographique de base, essentielle pour prévenir les problèmes et assurer une prise de décision efficace. Vermorel a mis en avant que, bien que les ordinateurs soient des outils pour mécaniser les décisions, une bonne compréhension de leurs capacités et de leurs limites est cruciale. Cette compréhension s’étend aux paradigmes de programmation, garantissant que les praticiens puissent optimiser les ressources et obtenir de meilleurs résultats.

Résumé Étendu

Dans un récent épisode de LokadTV, Conor Doherty, Responsable de la Communication chez Lokad, s’est engagé dans une discussion stimulante avec Joannes Vermorel, CEO et fondateur de Lokad, une entreprise française de logiciels spécialisée dans l’optimization prédictive de la supply chain. La conversation s’est penchée sur le monde complexe des ressources informatiques au sein de la supply chain, un sujet qui va bien au-delà de la simple utilisation des ordinateurs. Il requiert une compréhension nuancée de la manière dont ces machines fonctionnent de manière optimale, un concept que Vermorel désigne par “sympathie mécanique”.

Doherty a ouvert la discussion en soulignant la vaste étendue des ressources informatiques, englobant à la fois le matériel et les logiciels. Il a demandé à Vermorel une définition opérationnelle, qui a expliqué que les ressources informatiques comprennent toutes les catégories de matériel constituant un ordinateur moderne. Cette classification, bien que quelque peu arbitraire, a évolué au cours des 70 dernières années, donnant lieu à des catégories distinctes comme les CPU et la mémoire, chacune servant des objectifs précis dans l’écosystème informatique.

Vermorel a souligné l’importance de ces ressources dans le contexte de la gestion de la supply chain. Il a soutenu que si l’on accepte l’hypothèse selon laquelle les décisions supply chain sont mieux prises avec l’aide des ordinateurs, alors comprendre le matériel qui facilite ces calculs devient crucial. Cette compréhension ne se limite pas à connaître les composants physiques, mais concerne également la compréhension des catégories plus larges d’appareils et de leurs capacités informatiques.

Doherty a ensuite cherché à distiller ces informations pour les praticiens de la supply chain, en demandant comment ils devraient intégrer ce savoir dans leurs opérations quotidiennes. Vermorel a précisé que les ordinateurs ne sont pas intrinsèquement bons pour prendre des décisions ; ils sont simplement les meilleurs outils disponibles pour mécaniser les processus de prise de décision. Cette mécanisation, qui a stimulé le progrès pendant des siècles, s’étend désormais aux emplois de cols blancs grâce à l’utilisation des ordinateurs.

Vermorel a comparé le savoir fondamental sur les ressources informatiques à une connaissance géographique de base. Tout comme connaître l’emplacement des pays sur une carte est considéré comme essentiel, comprendre les bases du matériel informatique est fondamental pour les praticiens de la supply chain. Ce savoir aide à prévenir une série de problèmes potentiels et garantit que les décisions sont prises en ayant une compréhension claire de l’infrastructure informatique sous-jacente.

Doherty a approfondi la question de ce savoir fondamental, demandant s’il s’agissait de connaître des éléments simples comme l’emplacement d’un port USB ou des concepts plus complexes tels que le fonctionnement d’un disque SSD. Vermorel a répondu qu’il s’agit davantage de comprendre les abstractions et les catégories stables de préoccupations qui perdurent en informatique depuis des décennies. Cela inclut la mémoire, le stockage, la bande passante, le calcul arithmétique et les processus d’entrée/sortie.

La conversation a ensuite porté sur la manière dont ce savoir fondamental se traduit par une meilleure prise de décision. Vermorel a expliqué que sans une compréhension de base du matériel, les processus de prise de décision peuvent sembler relever de la magie, rendant difficile l’évaluation de la pertinence d’une méthode pour le matériel disponible. Il a utilisé l’analogie du choix d’une voiture pour illustrer ce point. Tout comme choisir une voiture nécessite de comprendre son usage prévu, sélectionner des ressources informatiques requiert de connaître leurs capacités et leurs limites.

Vermorel a également abordé l’importance des paradigmes de programmation et leur place dans le processus de prise de décision. Il a noté que, bien que des cas d’utilisation spécifiques ne soient pas toujours évidents, avoir une compréhension fondamentale de concepts tels que l’analyse statique, la programmation par tableaux et le contrôle de version est crucial. Ce savoir aide les praticiens à éviter de tâtonner dans l’obscurité et garantit qu’ils peuvent prendre des décisions éclairées concernant les outils informatiques qu’ils utilisent.

En conclusion, Vermorel a souligné que les pratiques modernes de la supply chain dépendent fortement du matériel informatique. Même les entreprises qui se considèrent comme low-tech utilisent massivement les ordinateurs, que ce soit pour des algorithmes complexes ou des outils simples comme Excel. Par conséquent, disposer d’une compréhension fondamentale des ressources informatiques n’est pas seulement bénéfique, mais essentiel pour une gestion efficace de la supply chain. Ce savoir permet aux praticiens de prendre des décisions éclairées, d’optimiser leurs ressources informatiques et, en fin de compte, d’obtenir de meilleurs résultats pour leurs organisations.

Transcription complète

Conor Doherty : Bon retour sur LokadTV. Aujourd’hui, Joannes et moi allons discuter des ressources informatiques en supply chain. Comme vous allez le constater, il s’agit de bien plus que de simplement savoir utiliser un ordinateur. Au contraire, il faut une bonne compréhension de son fonctionnement optimal. Cela s’appelle la sympathie mécanique, et comme nous le verrons, une bonne sympathie mécanique peut se traduire par une meilleure utilisation des ressources informatiques et, en fin de compte, par de meilleures décisions. Maintenant, comme toujours, si ce que vous entendez vous plaît, pensez à vous abonner à notre chaîne YouTube et à nous suivre sur LinkedIn. Et sur ce, je vous présente la conversation d’aujourd’hui.

Alors, Joannes, les ressources informatiques en supply chain, c’est un concept très vaste. Il englobe à la fois le matériel et les logiciels. Pour les besoins de la conversation d’aujourd’hui, et en gardant à l’esprit que l’audience est issue de la supply chain, quelle serait une bonne définition opérationnelle des ressources informatiques ?

Joannes Vermorel : Les ressources informatiques est un terme général qui couvre toutes les catégories de matériel constituant un ordinateur moderne. De nos jours, la séparation entre ces catégories est un peu arbitraire, mais seulement un peu. Il n’y a rien dans la nature qui dicte qu’il y ait une catégorie d’appareils que nous devrions appeler CPU (unités centrales de traitement) et une autre catégorie d’appareils que nous devrions appeler mémoire, etc. C’est une co-évolution de la conception des ordinateurs et du rôle du marché qui a façonné certaines niches, donnant lieu à des entreprises qui se révèlent avoir des appareils vraiment compétitifs pour des usages spécifiques. C’est ainsi que cette évolution s’est opérée. Maintenant, 70 ans après l’introduction des ordinateurs, nous avons des catégories très claires d’appareils informatiques qui ne font pas tout de bout en bout. Ils sont comme des composants dans le calcul.

Maintenant, pourquoi est-il important de disposer de cela ? Quand je parle de ressources informatiques, je fais référence de manière large au matériel mais aussi, implicitement, à la catégorie d’appareils et à ce qu’ils vous apportent pour effectuer des calculs. Pourquoi est-ce important pour la supply chain ? Parce que si nous considérons la supply chain comme un exercice de prise de décision et si nous partons du principe que ces calculs seront mieux effectués par des ordinateurs, alors il s’agit littéralement de la couche physique qui portera ces calculs. Ce geste de foi n’est, après tout, qu’un geste modeste. Les ordinateurs ont fait leurs preuves et se révèlent aujourd’hui tout à fait capables. Mais néanmoins, tout part de cette vision selon laquelle toutes ces décisions, ces millions de décisions qu’une supply chain de grande envergure doit prendre, seront finalement réalisées par un ordinateur d’une manière ou d’une autre.

Ainsi, si nous commençons à y réfléchir, nous devrions accorder un peu plus d’attention à cette couche matérielle. La situation est devenue beaucoup plus complexe au cours des quatre dernières décennies. Les ordinateurs continuent de progresser, mais de manière beaucoup plus complexe et moins intuitive par rapport à ce qui se passait jusqu’à la fin des années 90.

Conor Doherty : D’accord, pour résumer, les ordinateurs sont performants en matière de prise de décisions. Mais comment un praticien de la supply chain qui écoute tout cela s’intègre-t-il dans la conversation d’aujourd’hui ? Quel est le message essentiel, la vision globale pour lui ?

Joannes Vermorel : Tout d’abord, je dirais que les ordinateurs ne sont pas particulièrement doués pour prendre des décisions. Ce sont simplement les outils à notre disposition, et actuellement nous n’avons aucune option viable pour mécaniser les processus de prise de décisions. C’est en quelque sorte un acte de foi. Pourquoi voulons-nous mécaniser ? Parce que la mécanisation a été le moteur du progrès pendant les deux, voire trois derniers siècles. Au 20e siècle, c’était la mécanisation des emplois manuels avec des améliorations de productivité absolument stupéfiantes, de l’ordre de 100 fois. Maintenant, au 21e siècle, nous voyons exactement la même chose mais pour les emplois de cols blancs, et cela se fait grâce aux ordinateurs. On pourrait imaginer un univers parallèle où cela se ferait avec d’autres choses, mais pour l’instant, la meilleure option que nous ayons reste les ordinateurs.

Maintenant, pourquoi est-ce important ? Je dirais que nous devons considérer les ressources informatiques et le matériel informatique comme faisant partie des connaissances fondamentales. Quand a été la dernière fois où il vous a été utile de savoir où se trouve le Canada sur une carte du monde ? Quand a été la dernière fois où il vous a été utile de savoir que la Russie n’a pas de frontière avec le Brésil ? Ce sont le genre de choses qui, au quotidien, ne vous semblent pas très pratiques, par exemple le simple fait de connaître les bases de la géographie mondiale. Pourtant, si vous demandiez à la vaste majorité des personnes présentes dans cette audience, elles diraient que c’est important. Que penseriez-vous de quelqu’un qui ne pourrait pas situer la Chine, le Canada ou la Russie sur une carte du monde ? Cela semblerait très étrange, et vous ne confieriez probablement pas à cette personne de nombreux rôles dans votre organisation.

Vous pouvez donc le considérer en partie comme de la culture générale, mais c’est aussi du savoir fondamental. Si vous n’y connaissez rien, cela va créer des problèmes. Quels types de problèmes ? Cela dépend beaucoup des spécificités de la situation, de l’entreprise et du secteur. Mais vous pouvez vous attendre à toute une série de problèmes. Je crois que la connaissance du matériel informatique et des ressources informatiques relève de ces savoirs fondamentaux dont les praticiens de la supply chain doivent être conscients. Ils devraient avoir une véritable sympathie mécanique, un terme emprunté à la Formule 1, à ce sujet.

Conor Doherty : Eh bien, j’apprécie l’analogie que vous employez, et je vais essayer de l’explorer pour clarifier ce point. Si vous dites que le savoir fondamental consiste à savoir que le Brésil et la Russie ne partagent pas de frontière, c’est une granularité de connaissance géographique. Une autre consiste à savoir combien de capitales possède l’Afrique du Sud. Ce sont des niveaux ou granularités de conscience géographique qualitativement différents. Pour transposer cette différence au matériel ou aux ressources informatiques, quand vous parlez de savoir de base, faites-vous référence à savoir où se trouve le port USB de ma souris, ou à comprendre comment fonctionne un disque SSD ? Quel est l’ordre de grandeur du savoir ici ?

Joannes Vermorel : Je parle davantage des abstractions. Il existe une infinité de détails anecdotiques sur le matériel informatique. Il ne s’agit pas de connaître chaque appareil et son tarif. Si vous êtes un geek, vous pouvez prendre plaisir à lire à ce sujet, ce que je fais. Mais fondamentalement, il s’agit plutôt de ces très grandes catégories de ressources bien établies. Cela dépend un peu de l’architecture, mais ces architectures sont restées très stables pendant au moins cinq décennies, ce que vous pouvez raisonnablement espérer perdurer.

De quoi parlons-nous ? Nous parlons de choses comme la mémoire, la mémoire volatile, le stockage persistant, la bande passante, le calcul arithmétique, les entrées et sorties (I/O), le débit, la latence. Toutes ces préoccupations ont constitué des catégories de préoccupations qui sont restées stables pendant de nombreuses décennies. C’est ce que j’entends par avoir ce savoir de base pour comprendre quelles sont ces catégories de préoccupations et le matériel informatique correspondant. Comment tout cela s’assemble-t-il pour faire fonctionner un ordinateur moderne ?

Si l’on prend du recul en termes de couches, vous voulez en fin de compte que vos processus de prise de décision soient calculés grâce à ce matériel de calcul. Si vous n’avez aucune connaissance de ce qui se passe au niveau matériel, c’est complètement magique. Quelles sont les chances que vous puissiez même comprendre si une méthode est adaptée ou non au matériel dont vous disposez ? Je ne parle pas ici d’une compréhension ultra détaillée, juste d’une compréhension très basique de si cela fonctionnera ou non.

Conor Doherty: Par exemple, vous utilisez l’expression… Désolé, laissez-moi revenir d’une étape. Vous avez nommé quelques paradigmes de programmation. Je pense que c’était dans l’une de vos conférences. Vous avez parlé des paradigmes de programmation, de l’analyse statique, de la programmation RA, de la programmation différentielle, du contrôle de version, de la persistance, de tous ces concepts. Ma question est la suivante : comment s’articulent-ils pour permettre de prendre les meilleures décisions dont vous parlez ?

Joannes Vermorel: Ce sont des connaissances fondamentales, alors n’attendez pas de ma part des cas d’usage très spécifiques, tout comme en géographie de base. La dernière fois où vous aviez absolument besoin de savoir cela ? Probablement jamais. C’est omniprésent. Le problème est que si vous avez des couches de connaissances fondamentales manquantes, vous tâtonnez dans le noir. Vous ne voyez même pas que vous êtes dans le noir. Vous ne réalisez même pas qu’il y a tant de choses que vous ne comprenez pas. C’est vraiment mon point.

Revenons en arrière. Vous voulez générer ces décisions avec un ordinateur. Cela signifie que vous allez sélectionner des fournisseurs, probablement pas qu’un seul. Vous allez acheter ou louer des ressources de cloud computing. Vous pouvez totalement déléguer la tâche à votre IT, mais pourquoi l’IT serait-elle excellente pour choisir du matériel pour quelque chose dont elle ne sait rien ? Par exemple, si je vous dis : “Chère IT, s’il vous plaît, choisissez-moi la meilleure voiture”, sans spécification. D’accord, très bien. Alors, l’IT dit : “Ok, je vous apporte une Formule 1.” Et vous rétorquez : “Eh bien, en fait, je veux rouler sur des dunes le long de la plage.” La Formule 1 s’avère alors être un véhicule complètement nullissime parce qu’elle n’est absolument pas conçue pour rouler dans le sable.

Si tout ce que vous me demandez, c’est de prendre quelque chose de bon, ils choisiront quelque chose de fondamentalement bon, comme une Formule 1. Est-ce une bonne voiture ? Oui, c’est une bonne voiture pour un usage spécifique. Mais si vous dites : “Je veux une voiture dans laquelle je peux garer ma famille de huit personnes”, cela va donner une définition bien différente de ce qui est bon. Nous avons cette illusion que, lorsqu’il s’agit d’informatique, du matériel de calcul et des choses de calcul en général, c’est une question de spécialistes. Tout comme pour choisir une voiture, je ne suis pas un spécialiste de l’automobile, donc je vais simplement dire au service automobile de m’en choisir une bonne et de s’en occuper. Ces personnes ont tellement d’options quant à ce que « bon » signifie réellement qu’elles en choisissent une au hasard. Ensuite, vous pouvez vous plaindre en réception en disant : “Oh, mais le coût de cette Formule 1 est extravagant. Je ne peux même pas mettre une deuxième personne dans la voiture et, à l’endroit où je veux rouler, c’est-à-dire dans le sable, elle ne fera même pas 10 mètres avant que les roues ne perdent leur adhérence à cause du faible dégagement.” S’il s’agissait d’une voiture, les gens conviendraient que ce serait ridicule.

Mais quand on parle d’informatique, dans la plupart des entreprises, les gens trouvent parfaitement acceptable de ne pas s’intéresser au cas. Bien que, encore une fois, je revienne à la pratique de supply chain. Une pratique moderne de supply chain est extrêmement dépendante de ce matériel de calcul. Les supply chains ont été digitalisées il y a des décennies, et même les entreprises qui pensent être low-tech s’appuient énormément sur les ordinateurs, même s’il ne s’agit que d’Excel.

Si vous dépendez de ces outils au quotidien, vous dépendez d’eux de manière très élaborée. Par exemple, je dépends de la disponibilité de l’eau, mais je n’ai pas besoin de connaître quoi que ce soit à propos de son approvisionnement. C’est exact, car l’eau en tant que produit est extrêmement simple. Elle est chimiquement simple, et quand vous parlez d’eau du robinet, vous attendez 99,99 % H2O plus une infime quantité de minéraux et un peu de chlore pour des raisons sanitaires, et c’est tout.

Donc, vous voyez, c’est et la température devrait être quelque chose comme entre 10 et 20 degrés, et c’est tout. C’est donc quelque chose d’extrêmement simple. Voilà pourquoi vous n’avez pas, vous, la couche d’abstraction qui se dit : “Je reçois de l’eau du robinet et elle est bonne à boire.” Je peux me permettre de ne rien savoir sur ce qui se passe en amont. Mais le problème, et c’est là que j’arrive au point des ressources de calcul, c’est que les ressources de calcul sont multidimensionnelles. Vous savez, ce n’est pas quelque chose de simple comme l’eau. C’est bien plus comme une voiture. Il y a tellement de types de voitures différents, tellement de manières différentes de qualifier une bonne voiture.

Si je dis : “Qu’est-ce que de l’eau de bonne qualité ?” vous savez, sauf si vous faites des expériences très, très spécifiques, du type transformation industrielle nécessitant de l’eau ultra-pure et autres, pour pratiquement toutes les situations que vous rencontrerez dans la vie, l’eau du robinet basique est exactement ce qu’il vous faut. Vous n’avez donc rien besoin de savoir à ce sujet parce que, encore une fois, vous traitez avec un produit extrêmement simple. Mais si vous traitez avec un produit multidimensionnel, comme une voiture, alors vous devez en connaître une ou deux choses si vous voulez l’acheter.

Donc, encore une fois, si nous nous tournons vers des praticiens de la supply chain, il s’avère que vous dépendez énormément des ressources de calcul pour faire une multitude de choses. Ces choses deviendront encore plus prépondérantes à l’avenir. Qu’est-ce qui vous fait penser que vous pouvez être complètement ignorant de la couche physique de tout cela ?

Conor Doherty: Eh bien, il y a quelques points là-dedans, dont l’un est que les supply chains sont évidemment très complexes. Vous essayez de résoudre beaucoup, beaucoup de choses, et cela dépend du contexte. Par exemple, peut-être que vous voulez que la voiture roule dans le désert, que vous la fassiez rouler sur des collines, que vous la fassiez rouler en ville. Ce sont tous des contextes différents, mais il existe néanmoins des propriétés communes en ce qui concerne ce que, du moins selon nous, les entreprises devraient essayer de faire avec leurs ressources de calcul. Pouvez-vous donc développer un peu ce point ?

Joannes Vermorel: Oui, je veux dire, voilà le fait : d’accord, vous voulez, disons, analyser en base votre historique transactionnel. Ce serait quelque chose. D’accord, cela signifie que ces données doivent être stockées. Alors, où seront-elles stockées ? Quel type de matériel ? Quelles seront les caractéristiques de ce matériel ? Si vous voulez stocker les données puis y accéder, cela a-t-il un impact ? La réponse est oui, ça en a un. Juste pour vous donner une idée très simple, considérons que vous souhaitez stocker ces données sur un disque en rotation.

Peu importe que ce soit votre disque en rotation ou quelque chose que vous louez sur une plateforme de cloud computing. Si les données sont stockées sur un disque qui tourne, cela signifie qu’en moyenne, lorsque vous voulez accéder à une partie des données, le disque devra tourner en moyenne d’un demi-tour pour que vous puissiez accéder à la zone. Vous savez, c’est simplement parce que les données peuvent être n’importe où sur le disque. Si vous voulez accéder à un morceau de données, en moyenne le disque devra tourner d’un demi-tour.

D’accord, très bien. Quelles en sont les conséquences ? Eh bien, la conséquence est : à quelle vitesse le disque peut-il tourner ? Un disque tournera typiquement à quelque chose comme 7 000 rotations par minute, et s’il s’agit d’un disque très haut de gamme, il pourra peut-être atteindre 11 000 ou 12 000 rotations, mais c’est tout. Donc, rotations par minute. Cela signifie que, vous savez, en termes de latences, vous devriez vous attendre à environ 20 millisecondes pour accéder à n’importe quelle partie des données.

Vous diriez donc : “Eh bien, 20 millisecondes, ça semble court.” Mais est-ce vraiment le cas ? Parce que 20 millisecondes signifient qu’en une seconde, vous ne pouvez accéder, si vous devez parcourir tout votre disque, qu’à seulement 50 morceaux de données par seconde. Si vous devez sauter d’un endroit à l’autre, 50 par seconde, ce n’est pas beaucoup. Si vous avez des millions, des dizaines de millions d’enregistrements à récupérer, vous verrez très vite que cela va rapidement dégénérer en délais totalement fous.

Oui, mais si la récupération des données, en raison du fait que vous devez parcourir le disque autant, prend des jours, ce n’est vraiment pas acceptable. Alors peut-être que je peux, vous savez, prendre beaucoup plus de disques de plus petite capacité, et j’aurai, vous savez, un débit plus élevé pour ces accès dispersés. Ou peut-être puis-je même, vous savez, utiliser une autre catégorie de stockage entièrement et opter pour des SSD, des disques à état solide, qui offrent des latences bien, bien meilleures pour ces accès aléatoires.

Mais vous voyez, c’est exactement le genre de choses où, encore une fois, si vous n’avez aucune connaissance sur les ressources de calcul et les catégories de matériel qui fournissent ces ressources, ce genre de questions ne se poserait même jamais dans votre réflexion. Et est-ce que cela peut vous nuire ? Vous savez, encore une fois, c’est la question. Ce que vous ne savez pas, cela peut-il vous nuire ? Je dirais oui, parce qu’encore une fois, vous allez en acheter beaucoup, soit directement, soit indirectement.

Vous les achèterez directement si votre IT department se contente d’acheter des ressources de cloud computing, mais vous les achèterez aussi indirectement si vous choisissez un fournisseur supply chain software. Parce que, voyez-vous, si vous choisissez un fournisseur, vous optez pour une manière spécifique de consommer ces ressources de calcul afin d’obtenir le résultat désiré. Et ici, mon message est que si vous pensez que le fournisseur de logiciel moyen a la moindre compétence en la matière, vous êtes complètement dans l’illusion.

La grande majorité de mes concurrents – évidemment, c’est une opinion tranchée – je dirais que la très, très grande majorité de mes concurrents, les concurrents de Lokad, quand on regarde la direction et leur intérêt, de façon générale, n’ont aucun intérêt, aucune affinité mécanique pour le matériel de calcul. Et par conséquent, il ne devrait pas être surprenant que leurs logiciels, en conséquence, soient horriblement inefficaces. Et pourquoi cela ? Eh bien, cela revient au fait que si vous ne prêtez aucune attention à votre matériel, pourquoi penseriez-vous qu’au final, le logiciel que vous allez construire au-dessus en fera bon usage ?

Vous savez, ce serait comme choisir une Formule 1, quelle que soit la route sur laquelle vous voulez rouler, puis vous vous demandez pourquoi, sur la plage, c’est un véhicule aussi pourri. Vous savez, surprise, surprise, c’est ce qui arrive quand on ne prête aucune attention au matériel de calcul.

Donc encore, si vous pouviez faire confiance à un monde parfait, vous pourriez faire confiance, vous savez, à des consultants, à des fournisseurs de logiciel, et ces personnes auraient pris toutes les bonnes décisions pour vous. Mais il s’est avéré que, du fait que la grande majorité des praticiens de la supply chain est complètement ignorante, alors les fournisseurs de logiciel peuvent aussi se permettre d’être complètement ignorants. Pourquoi ne le pourraient-ils pas, après tout, si les clients ne voient pas la différence au moment d’acheter le logiciel ou la solution ? Peu importe, je veux dire, cela n’a d’importance que lorsque les conséquences de cette ignorance se font sentir.

Conor Doherty: Eh bien, d’accord, alors tout d’abord, rien de mal à avoir une opinion, c’est exactement ce que nous faisons ici. Mais quand vous dites qu’en fin de compte, lorsque les entreprises achètent un logiciel auprès d’un fournisseur – je pense que vous parliez de consommer des ressources pour obtenir ce qu’elles veulent ou ce que vous voulez –, en fin de compte, soyons pratiques, nous parlons de prise de décision. Vous avez donc donné un peu de théorie, mais pouvez-vous être un peu plus concret pour les curieux ? Comment une meilleure utilisation des ressources de calcul, telle que vous la décrivez, influence-t-elle ou se traduit-elle en décisions, en choix faits dans le monde réel ?

Joannes Vermorel: Ainsi, lorsque vous avez des décisions, vous avez de très, très nombreuses manières de concevoir des recettes numériques qui finiront par générer cette décision. Le fait est que si la manière dont vous consommez vos ressources de calcul est incroyablement inefficace – et permettez-moi de donner un exemple – si vous commencez à utiliser, disons, une base de données relationnelle, une base de données transactionnelle, une base de données SQL, c’est la même chose, cela n’a rien à voir avec l’argent. En effet, si vous utilisez une base de données transactionnelle et que vous souhaitez réaliser des recettes analytiques, des recettes numériques, en effectuant un certain type de traitement numérique, vous paierez un surcoût probablement d’un facteur 100, soit au moins deux ordres de grandeur, voire 300, trois ordres de grandeur.

Et pourquoi cela ? C’est parce que cette couche logicielle, la couche transactionnelle, vous apporte des propriétés très intéressantes, mais elles n’ont rien à voir avec le calcul analytique. Elle vous procure essentiellement les quatre propriétés connues sous le nom d’ACID : atomicité, cohérence, isolation, durabilité. Ces éléments sont très utiles pour les processus transactionnels. Ils garantissent, par exemple, que si vous voulez déclarer qu’un fournisseur a été payé, vous ne pouvez jamais vous retrouver dans une situation où l’argent a été envoyé, l’ordre a été passé à la banque, mais la facture du fournisseur n’a pas été réglée juste parce que, par exemple, le système informatique s’est planté à mi-chemin de l’opération.

Ainsi, en théorie, vous pourriez vous retrouver dans une situation où vous avez déjà émis l’ordre de virement mais n’avez pas enregistré le fait que la facture d’un fournisseur a été réglée. Ainsi, la prochaine fois que vous redémarrerez le système, vous émettrez un second paiement et paierez effectivement le fournisseur deux fois. C’est ce genre de choses que peut entraîner une couche transactionnelle. C’est très, très important pour les opérations transactionnelles, où il y a essentiellement un compte qui est incrémenté et un autre, au sens de la comptabilité, qui est décrémenté. Vous voulez que ces opérations se produisent logiquement en même temps afin de ne jamais désynchroniser ces éléments.

Très bien, mais si vous utilisez ce genre de paradigme logiciel pour construire vos ressources analytiques, vous devenez incroyablement inefficace. Et, d’ailleurs, surprise, surprise, c’est exactement ce que 99 % de mes concurrents font. Qu’est-ce que cela signifie en termes de prise de décision ? Eh bien, si la manière dont vous utilisez les ressources de calcul commence par un surcoût d’un facteur 100, cela signifie que vous êtes cantonné à des recettes numériques très, très simplistes. Dès que vous atteignez un minimum de complexité, vous êtes complètement hors budget en termes de ressources informatiques. Cela signifie que les coûts deviennent vraiment extravagants très rapidement.

Vous voyez, ceci n’est pas un argument publicitaire. Si vous ne maîtrisez pas votre budget de ressources de calcul, vous pouvez finir par atteindre des niveaux de dépenses complètement fous. Pour vous donner un ordre d’idée, nombre de mes pairs – non pas des concurrents, mais des pairs qui seraient des entreprises de software as a service traitant de lourdes charges analytiques – quand je regarde le S1, ce document que vous devez publier lorsque vous voulez entrer en bourse aux États-Unis, c’est très intéressant car c’est pratiquement un rapport aux investisseurs, aux futurs investisseurs. Ici, vous pouvez examiner la décomposition des dépenses sur les trois ou quatre dernières années.

La plupart des entreprises de logiciels axées sur l’analyse, comme Lokad – qui ne se concentrent pas réellement sur la supply chain – peuvent porter sur n’importe quel domaine, par exemple la détection de fraude, le traitement des journaux système, etc. Elles consacraient typiquement la moitié de leurs dépenses aux ressources de cloud computing. Ainsi, le montant des dépenses est très, très important. Malgré le fait de payer, vous savez, des ingénieurs extrêmement coûteux et une force de vente tout aussi onéreuse, elles parviennent néanmoins à allouer la moitié de leurs dépenses aux fournisseurs de cloud computing. Vous voyez donc que l’idée selon laquelle le coût des ressources informatiques serait négligeable est complètement absurde pour la plupart des éditeurs de logiciels analytiques comme Lokad.

Des systèmes – et non pas des systèmes d’intelligence, mais plutôt des systèmes de rapports ou d’indigence – ces dépenses peuvent être très, très importantes. Quand je dis que si vous êtes inefficace, vous dépensez 100 fois plus, vous voyez que si vous consacrez déjà la moitié de vos revenus aux ressources informatiques, dépenser 100 fois plus n’est tout simplement pas envisageable. Ce n’est même pas quelque chose de remotement possible. Cela signifie donc que, pour rester dans le budget, que faites-vous ? Eh bien, vous augmentez simplement le prix. C’est ce qu’ils font, mais même cela a ses limites. Vous pouvez doubler, voire quadrupler votre prix, mais vous ne pouvez pas multiplier vos prix par 100.

Donc, la plupart des éditeurs de logiciels optent pour des solutions plus simples et moins coûteuses, même si elles sont extrêmement basiques au point de desservir leurs clients. La réalité est qu’en tant qu’éditeur, ils ne peuvent se permettre quelque chose de moins dysfonctionnel parce que ce serait beaucoup trop onéreux. Et pourquoi ne peuvent-ils pas se le permettre ? Parce qu’ils gaspillent absolument leurs ressources informatiques de manière démesurée.

Conor Doherty: Eh bien, il me vient à l’esprit que lorsque vous parlez et expliquez comment vous pensez que les ressources informatiques devraient être allouées, c’est dans la quête de décisions fondamentalement meilleures. À vos yeux, c’est le problème à résoudre. Mais ce n’est pas nécessairement le même paradigme que toutes les entreprises – ou plutôt, ce n’est pas le paradigme appliqué par toutes –. Par exemple, vous pourriez être une entreprise qui privilégie quelque chose comme viser un taux de service ou viser une précision des prévisions, et c’est l’objectif, le Graal que vous poursuivez. Comment l’allocation des ressources informatiques différerait-elle dans ce cas ? Et n’hésitez pas à commenter. Joannes Vermorel: Donc, d’accord, vous vous fixez un objectif. Ici, je ne conteste pas cette partie. Quand je parle de meilleures décisions, je fais référence à n’importe quelle métrique, n’importe quel objectif que vous vous êtes fixé. Cela n’a donc aucune importance. Si vous voulez un meilleur taux de service, très bien. C’est votre objectif. Maintenant, vous vous êtes fixé un objectif et vous disposez d’une puissance de traitement, de ressources informatiques, que vous pouvez utiliser pour obtenir des décisions qui seront meilleures selon les objectifs que vous vous êtes assignés. Très bien.

Clarifions maintenant quel est le paradigme ambiant pour pratiquement tous mes concurrents. Le paradigme ambiant, c’est que vous aurez des ingénieurs qui commenceront à travailler sur quelque chose, puis, dès que ce quelque chose est compatible avec le meilleur matériel que l’argent peut acheter, ils arrêtent de travailler et se mettent à vendre le produit aux clients. Alors, à quoi cela ressemble-t-il ? Cela signifie que, d’accord, je veux faire le réapprovisionnement de stocks réapprovisionnement pour un réseau de distribution. Ainsi, j’ai, disons, 20 millions de SKUs. Très bien. D’abord, j’essaie diverses approches, ça ne fonctionne pas, alors je reviens, par exemple, à une analyse de stock de sécurité, qui est extrêmement triviale en termes de ressources informatiques.

Et puis, parce que mon système est tellement inefficace malgré un matériel informatique extrêmement coûteux, je parviens à le faire fonctionner. Ensuite, j’arrête et je le vends au client. Quelle était donc la logique de ce paradigme ? Parce qu’en réalité, dans l’industrie des logiciels, c’était – je pense – le paradigme dominant jusqu’à la fin des années 90. Ce paradigme reposait essentiellement sur l’idée que le matériel informatique progressait de façon exponentielle. L’idée était donc de se procurer le meilleur matériel que l’argent pouvait acheter et, dès qu’il fonctionnait – que vous aviez quelque chose qui fonctionnait d’une certaine manière dans ces limitations, même si les coûts étaient exorbitants, même si vous n’utilisiez pas de façon optimale vos ressources informatiques – cela n’avait pas d’importance.

Pourquoi ? Parce que vous bénéficiez d’une progression exponentielle du matériel informatique sur tous les indicateurs. C’est ce que les gens appellent la loi de Moore, mais en réalité, il existait tant d’autres lois pour tout. Toutes les ressources informatiques progressaient, tous les indicateurs s’amélioraient, et c’était en grande partie l’une des idées qui a rendu Microsoft extrêmement prospère dans les années 90. L’idée est que si ça fonctionne, peu importe à quel point la performance est médiocre, car dans cinq ans, le matériel informatique aura tellement progressé que ces ressources deviendront négligeables.

Cela a fonctionné jusqu’à la fin des années 90, car depuis essentiellement l’an 2000 dans ce domaine, nous avons des catégories entières d’indicateurs qui ne se sont pas améliorées. Par exemple, la latence entre le CPU et la mémoire n’a pratiquement pas changé au cours des deux dernières décennies. Du fait que nous sommes désormais limités par la vitesse de la lumière, cela ne changera pas dans un avenir prévisible.

Un autre élément est, encore une fois, la vitesse de la lumière. Les paquets sur Internet, sur de longues distances, se déplacent désormais à environ deux tiers de la vitesse de la lumière, donc il n’y a pas vraiment de marge pour améliorer la vitesse des paquets sur Internet, car nous sommes déjà très proches de la vitesse de la lumière. Nous pouvons disposer de plus de bande passante, ce qui nous permet de pousser beaucoup plus de paquets, sans problème, mais en termes de vitesse brute des paquets eux-mêmes, nous sommes désormais très proches des limites de la physique – du moins de la physique telle que nous la connaissons.

C’est donc le genre de situation où, encore une fois, ce paradigme qui était très répandu dans l’industrie des logiciels à la fin des années 90 – celui de “faire quelque chose qui fonctionne, puis le vendre, sans se soucier des performances parce que c’est une quête vaine” – verra l’industrie du matériel améliorer tellement tout cela que toutes ces préoccupations de performance deviendront sans importance en quelques années seulement. C’était cet état d’esprit.

Il est intéressant de noter que nous continuons à voir de très belles avancées dans le matériel informatique, mais ces progrès sont devenus très subtils. Vous avez toujours des progressions exponentielles, mais dans des domaines très spécifiques – pas tous les indicateurs, seulement certains. Ce qui est intéressant, c’est que la majeure partie de l’industrie des logiciels B2C y prête beaucoup attention. Par exemple, l’industrie du jeu vidéo accorde une énorme importance à ces détails. Mais en ce qui concerne les logiciels d’entreprise, 99 % d’entre eux vivent encore comme dans la fin des années 90, sans prêter attention, fonctionnant comme si, dans cinq ans, la progression du matériel informatique avait rendu le coût de leur système négligeable. Ce n’est pas le cas.

En fait, du fait que la quantité de données gérées par les entreprises ne cesse d’augmenter, nous nous retrouvons dans une situation où, d’année en année, le coût nécessaire pour maintenir vos systèmes opérationnels tend, pour la plupart des éditeurs de logiciels, à augmenter plus rapidement que la baisse des prix du matériel informatique. Ainsi, année après année, vous finissez par dépenser encore plus pour conserver pratiquement le même niveau fonctionnel de qualité dans vos processus de prise de décision – ou dans le support de ces processus s’ils ne sont pas entièrement automatisés.

Conor Doherty: Eh bien, la progression du matériel – ou des capacités informatiques – est devenue subtile, je crois que c’était le terme que vous avez utilisé. Elle est subtile ; il n’y a plus de sauts exponentiels.

Joannes Vermorel: C’est dans des directions spécifiques, et non dans toutes les dimensions. Dans les années 90, l’intérêt était que tout s’améliorait sur tous les plans. Il n’y avait pas un seul indicateur qui ne progressait pas. De nos jours, de nombreux indicateurs stagnent littéralement depuis une décennie.

Si vous examinez, par exemple, la quantité de chaleur qu’un ordinateur peut dissiper – votre ordinateur doit se débarrasser de la chaleur – vous constaterez qu’il peut employer des câblages en cuivre, des ventilateurs, et d’autres dispositifs pour extraire cette chaleur de l’intérieur afin d’éviter la surchauffe. Mais nous avons déjà atteint la limite de ce qui est réalisable avec l’air. Des limites ont été atteintes il y a deux décennies. Vous pouvez utiliser l’eau pour obtenir de meilleures performances. Et si vous voulez aller très loin, vous pouvez opter pour de l’azote liquide. C’est assez impraticable, mais c’est envisageable pour de beaux benchmarks, etc.

Nous avons donc atteint les limites. Nous ne disposons d’aucun matériau magique qui nous permette d’évacuer deux fois plus de chaleur. Je veux dire, on pourrait peut-être utiliser le diamant. Le diamant est un excellent conducteur de chaleur, mais l’idée d’avoir des kilogrammes de diamants pour évacuer la chaleur reste encore très éloignée. Même cela ne nous offrirait qu’un modeste gain comparé au cuivre, qui est déjà un conducteur excellent.

Conor Doherty: Eh bien, cela démontre en fait un peu plus mon propos. Pour conclure, si…

D’accord, je vais prendre l’exemple que vous venez de donner. Vous parliez donc de la différence entre le fil de cuivre et les diamants en tant que conducteurs de chaleur. Pour extraire un peu plus de performance des propriétés d’évacuation de chaleur d’un ordinateur, cela va nécessiter une compréhension assez nuancée et spécialisée de l’ingénierie informatique. Revenant au sujet principal, comment l’augmentation de votre savoir fondamental ambiant se traduit-elle par une meilleure performance de la supply chain alors que les marges sont aussi fines que vous le décrivez ?

Joannes Vermorel: Non, je pense qu’encore une fois, le savoir fondamental permet de clarifier l’ensemble du tableau. Votre service informatique achète-t-il, ne serait-ce que globalement, le bon type de matériel ? En avez-vous la moindre idée ? Pouvez-vous même discuter de la question avec votre service informatique ? Si ce n’est pas le cas, pourquoi penser que ce qu’ils achètent pourrait avoir le moindre sens ?

Encore une fois, pensez à la Formule 1 pour aller à la plage. Cela n’a aucun sens, mais c’est exactement ce qui se passe lorsque les gens ignorent complètement ce qui est en jeu. Lorsque vous souhaitez choisir un fournisseur, pouvez-vous même engager une discussion intelligente sur la manière dont il consomme les ressources informatiques pour vous fournir de meilleures décisions ou un meilleur support dans le processus décisionnel ? Consommation-t-il ces ressources d’une manière appropriée par rapport au matériel informatique dont nous disposons ? L’architecture a-t-elle du sens ou pas du tout ?

Encore une fois, si vous pensez en termes de voiture, vous savez instinctivement tant de choses. L’aérodynamique, par exemple. Si vous deviez observer une voiture qui violerait massivement les lois de l’aérodynamique, vous penseriez : « D’accord, ce véhicule va subir une traînée d’air immense, sa consommation sera horrible. » Il n’y a pas d’alternative. Vous voyez, c’est le genre de chose où, grâce à votre savoir fondamental, tout devient instinctif. Vous n’avez pas nécessairement besoin qu’on vous dise, en voyant une voiture très basse, que son aérodynamisme sera bon et que, très probablement, elle ira plus vite.

Voilà le point. Vous n’avez même pas besoin de penser aux dynamiques fluides en jeu, etc. C’est instinctif. C’est le genre de chose qui, lorsqu’il s’agit de prendre de meilleures décisions, vous permet de repérer instinctivement des dysfonctionnements criants. Mon propos est que, du fait que 99,9 % des clients ou praticiens de la supply chain sont complètement aveugles à la question, s’il y a quelques geeks par-ci par-là, vous représentez une toute petite minorité. Et si vous êtes aveugle, cela signifie, encore une fois, que la réaction de l’écosystème – des éditeurs de logiciels, des fournisseurs de solutions, des consultants – est qu’ils n’ont pas besoin d’y prêter attention. Leurs clients n’y prêtent pas attention. Pourquoi le feraient-ils ?

Si vous viviez dans un pays où l’essence est gratuite, pourquoi les constructeurs automobiles s’intéresseraient-ils à la consommation de leurs voitures ? Pour eux, si l’essence est gratuite, c’est avant tout une préoccupation sans importance pour les clients. Si les clients n’y prêtent pas attention, les fabricants de voitures n’y prêteront pas attention. Et s’il en va de même pour les éditeurs de logiciels – si les clients sont désemparés et ne font pas attention – pourquoi les fournisseurs d’entreprise y accorderaient-ils de l’importance ? La réponse est, eh bien, ils n’y prêtent pas attention. En réalité, ils n’y prêtent tout simplement pas attention.

C’est pourquoi, de nos jours, les gens sont toujours surpris lorsqu’ils regardent les logiciels d’entreprise. Vous cliquez, vous voulez simplement voir un rapport, faire quelque chose de minimal, et cela prend des secondes. En termes de réactivité, les logiciels d’entreprise sont, en moyenne, très médiocres. Ils sont très lents. Si vous comparez, par exemple, avec une recherche sur le web – disons sur Google – en environ 50, voire 100 millisecondes, Google est capable de scanner le web et de vous fournir un aperçu des résultats correspondant à votre requête. C’est extrêmement rapide et réactif.

Inversement, vous voulez simplement exécuter une action très basique, comme « Je veux vérifier l’état de ce SKU », et cela prend des secondes. Ce qui est intéressant, c’est que cela prend des secondes sur le matériel informatique dont nous disposons en 2024. Il y a vingt ans, cela prenait déjà une seconde, malgré un matériel 100 fois moins performant. Qu’est-ce qui s’est passé ? Eh bien, ce qui s’est passé, c’est que les capacités supplémentaires de ce matériel ont tout simplement été gaspillées à cause d’un logiciel inefficace.

Conor Doherty: Merci. En parlant de savoir fondamental, alors que j’écoutais, il m’est venu à l’esprit qu’il y avait une petite nuance… on peut diviser ce que vous décrivez, et j’aimerais avoir votre avis. Pour reprendre une analogie précédente, vous avez dit que si vous preniez une voiture et que vous alliez dans le désert, serait-ce le meilleur véhicule pour le désert ? Il me semble qu’en termes de savoir fondamental, il existe à la fois une compréhension théorique et pratique.

Ainsi, vous pouvez avoir une compréhension théorique fondamentale du fonctionnement d’un moteur à combustion interne – c’est ce qui fait avancer la voiture. C’est une compréhension théorique. Il existe également un savoir pratique fondamental, c’est-à-dire, par exemple, si un pneu se crève, ai-je les compétences et les connaissances de base pour le changer ? Si le moteur ne démarre pas, suis-je capable d’effectuer une réparation élémentaire ? Et si vous devez conduire dans le désert, où vous serez seul, il vous faudra fondamentalement disposer à la fois d’un savoir théorique et, au minimum, d’un savoir pratique de base.

Pour revenir au sujet en cours, vous avez décrit en détail les connaissances fondamentales théoriques que les gens devraient posséder. En ce qui concerne les connaissances fondamentales pratiques, y a-t-il des compétences que vous pensez que tout le monde devrait avoir dans ce domaine?

Joannes Vermorel : Oui, encore une fois, en ce qui concerne le pratique, il s’agirait d’avoir quelques idées sur le type de niveaux de prix dont nous parlons. Vous savez, quel est le coût d’un téraoctet de stockage ? Quel est approximativement le coût d’un téraoctet de mémoire ? Quel est le coût d’un CPU qui offre un débit de calcul de 2 GHz ? Vous savez, encore une fois, avoir une estimation, si vous pouvez deviner un nombre qui n’est pas erroné d’un ordre de grandeur, c’est déjà très bien. Vous savez, le problème avec le domaine informatique, c’est que généralement, si les gens devaient deviner, leurs estimations seraient erronées de plusieurs ordres de grandeur.

Encore, si je vous demande quel est le poids d’une voiture et que je vous la montre, votre estimation sera peut-être erronée de 50 %. Vous dites, d’accord, une tonne et demie, et il s’avère que c’est une voiture électrique pesant plus de deux tonnes. D’accord, mais cela reste dans le même ordre de grandeur. Vous ne voyez pas une voiture et ne dites pas qu’elle pèse 20 kilogrammes ou 500 tonnes. Mais le problème, c’est que lorsque l’on demande aux gens quel est le coût d’un téraoctet de stockage persistant, le moins cher que l’on puisse trouver, certains vous donneront des prix qui varient, je ne sais pas, de 10 000 à 2, et autres, sans que personne ait vraiment la moindre idée de ce dont il retourne.

Et de même, si je vous demande quel est le coût d’une puce capable d’effectuer de l’ordre de 100 milliards d’opérations arithmétiques par seconde, quel chipset pourrait faire cela, quel en serait le coût ? Les gens répondent : je ne sais pas, 100 000 euros ou peut-être 50 $. Encore une fois, c’est ce genre de chose où, je dis, la connaissance pratique consiste à avoir quelques idées sur les niveaux de prix. Si vous êtes capable d’en deviner l’ordre de grandeur, vous êtes déjà dans la bonne direction pour concevoir des choses sensées.

C’est ce qui est vraiment étrange avec les ressources informatiques : il existe littéralement 15 ordres de grandeur. C’est, je pense, assez unique. Il n’existe aucun autre domaine dont je sache l’existence où les ordres de grandeur sont aussi incroyablement dispersés. 15 ordres de grandeur signifient que, d’une part, nous parlons d’unités – une addition, une multiplication, ce qui constitue une unité de calcul – et, d’autre part, nous parlons essentiellement de milliards de milliards. C’est vraiment un spectre impressionnant d’ordres de grandeur.

Cela est difficile à appréhender pour l’esprit. Et c’est pourquoi, d’ailleurs, quand j’ai dit que des erreurs pouvaient être commises en gaspillant des ressources informatiques, c’est que, encore une fois, l’analogie avec la voiture est trompeuse : même la pire voiture ne sera qu’environ 10 fois moins performante en termes de consommation que la meilleure. Disons, par exemple, que si je veux parcourir 100 kilomètres, une voiture super, super efficace va me consommer cinq litres d’essence pour ces 100 kilomètres.

Si je prends, par exemple, un SUV super lourd, inefficace et tout le reste, ce serait, disons, 50 litres. Un facteur 10. Avec les ordinateurs, ce n’est pas le cas. Ce serait comme si l’appareil le plus efficace consommait 5 centilitres pour 100 kilomètres et le moins efficace cinq mètres cubes pour ces mêmes 100 kilomètres. Les ordres de grandeur sont tout simplement extraordinaires. Et c’est pourquoi, d’un point de vue pratique, il faut avoir quelques idées sur les niveaux de prix et aussi savoir ce qui évolue et ce qui ne bouge pas.

Conor Doherty : Que voulez-vous dire par « ce qui évolue et ce qui ne bouge pas » ?

Joannes Vermorel : Par exemple, les GPU ont progressé en termes de tendances réseau. Les GPU ont progressé de manière fulgurante au cours des 5 dernières années et on s’attend toujours à ce qu’ils progressent tout aussi rapidement pour les cinq prochaines années. C’est donc une catégorie de ressources informatiques qui s’améliore rapidement. Elles progressent en termes de nombre d’opérations par seconde et aussi en termes de mémoire. C’est donc très, très positif. Les CPU suivent une trajectoire similaire. Ils progressent peut-être pas aussi vite, mais ils s’améliorent fortement en ce qui concerne le nombre de cœurs et la taille de la mémoire L3, qui est la mémoire intégrée au CPU.

Ils continuent de progresser rapidement. Par ailleurs, si l’on regarde la DRAM – la mémoire volatile utilisée comme mémoire principale de l’ordinateur, que vous perdez dès que vous éteignez votre machine – celle-ci a à peine évolué ces dix dernières années. Il y a très peu de fabricants, environ quatre usines dans le monde. C’est donc un marché où vous ne devez pas vous attendre à de réelles baisses de prix ni à trop de changements à court terme. En pratique, il s’agit d’avoir quelques ordres de grandeur, de connaître approximativement les niveaux de prix, de savoir à quoi s’attendre et d’avoir l’intuition que choisir, par exemple, du matériel de qualité professionnelle vous apportera quelque chose de vraiment différent du matériel grand public.

Selon ce que vous envisagez, parfois le meilleur que vous puissiez obtenir est du matériel grand public, et le meilleur que vous pouvez acheter en tant qu’entreprise n’est qu’un peu supérieur. Pourtant, dans d’autres domaines, ce qu’une entreprise peut acquérir est bien des ordres de grandeur meilleur que ce qui est généralement considéré comme adapté au marché des consommateurs. Encore une fois, c’est le genre de connaissance qui vous aide à naviguer dans le paysage, à choisir le bon fournisseur, ou plutôt à éliminer les fournisseurs incompétents. En y prêtant attention, vous serez capable de filtrer l’incompétence, que ce soit chez les consultants, les fournisseurs, ou même dans les projets internes. Cela compte.

Conor Doherty : Eh bien, vous avez évoqué plusieurs fois le coût, mais vous parliez surtout du coût direct d’acquérir physiquement le matériel. En ce qui concerne le coût direct puis indirect de ne pas être plus avisé dans l’utilisation de ses ressources informatiques, quels sont les ordres de grandeur dont nous parlons ici ? Et, pour cela, imaginez un grand magasin de détail – pardon, une grande entreprise de distribution, un grand réseau de distribution omnichannel – peignez le tableau que vous voulez, mais quel serait un ordre de grandeur raisonnable en termes de ce que vous risquez de perdre en n’étant pas plus avisé avec vos ressources informatiques ?

Joannes Vermorel : Eh bien, je dirais que, selon une estimation prudente, plus de 90 % des initiatives d’optimization de la supply chain échouent. Et une très grande partie de ces 90 %, en fait presque toutes les initiatives logicielles échouent, et une grande partie de cet échec est due en grande partie à des performances abyssales, même si ce n’est pas la seule raison. Maintenant, quand on pense à la performance, il faut l’envisager sous différents angles. Les gens se diraient, d’accord, j’ai besoin de faire mon réapprovisionnement des stocks chaque jour, donc le calcul complet doit pouvoir être réalisé en moins de 24 heures.

D’accord, c’est évident. Vous savez, si vous souhaitez exécuter le calcul chaque jour et que vous ne pouvez pas le terminer en 24 heures, vous êtes foutus. C’est donc la limite supérieure du temps que vous pouvez y consacrer. On pourrait penser que si vous achetez deux fois plus de ressources informatiques, vous pouvez faire le calcul deux fois plus vite. Eh bien, ce n’est pas automatique, car cela dépend vraiment de l’architecture logicielle que vous adoptez. Il existe de nombreuses architectures et patrons de conception qui ne se prêtent pas à ce que l’on appelle – terme technique – le « scale-out ». Ainsi, il existe de nombreuses approches où, même en ajoutant du matériel informatique en plus, vous n’obtenez tout simplement pas d’accélération.

Conor Doherty : En gros, des rendements décroissants.

Joannes Vermorel : Oui, et parfois sans aucun retour. Vous pouvez littéralement ajouter plus de ressources et n’obtenir aucune accélération. Cela dépend vraiment de la manière dont vous avez architecturé votre logiciel pour tirer parti de ces ressources informatiques supplémentaires. Passons à autre chose. Vous avez maintenant quelque chose qui peut calculer votre réapprovisionnement en, disons, quatre heures, et vous vous dites : « Super, pour votre réseau de distribution, cela ne prend que quatre heures. » Vous avez donc 24 heures dans la journée, ce qui laisse penser que vous exécuterez le calcul pendant la nuit. Est-ce satisfaisant ?

Eh bien, ma réponse est non, absolument pas. Pourquoi ? Parce qu’ici, vous regardez le processus une seule fois en production. Vous ne prenez pas en compte que votre recette numérique devra être ajustée et que vous devrez l’itérer de nombreuses fois pour parvenir à une version satisfaisante. Ce processus expérimental va s’avérer beaucoup plus coûteux.

Pour de nombreuses raisons. Tout d’abord, lorsque vous menez vos expériences, vous ne commencez pas en étant très rentable. Vous ne le serez qu’une fois que vous aurez identifié quelque chose qui, en termes de qualité de décision, vous fournit des résultats satisfaisants. Il est donc tout à fait normal de s’attendre, lors du prototypage de nouvelles recettes, à être beaucoup moins efficace. L’efficacité viendra par la suite, lorsque vous commencerez véritablement à optimiser la consommation des ressources informatiques.

C’est une chose. Mais il faut aussi payer des personnes pour qu’elles attendent que le calcul soit terminé afin d’examiner les résultats, d’évaluer et de lancer l’itération suivante. Et ici, le gros problème est que, si je reviens à l’initiative d’optimization de la supply chain logicielle qui échoue, ce processus peut devenir dramatiquement lent. Je veux dire, nous parlions de quatre heures. Disons à nouveau que les expériences vont être deux fois plus lentes du fait d’un environnement expérimental qui n’est pas aussi optimal.

Cela signifie donc huit heures. Cela veut dire que vous ne pouvez réaliser qu’une seule expérience par jour. Et si vous devez effectuer 500 itérations, cela va tout simplement prendre deux ans. Ce sera tellement lent que d’autres problèmes apparaîtront, comme par exemple les personnes effectuant les expériences finiront par changer de travail. Les ingénieurs avec lesquels vous travaillez ne resteront pas avec vous pendant 40 ans. À un moment donné, vous aurez des personnes qui auront commencé sur le projet, puis elles partiront, et vous devrez engager du nouveau personnel qui ne se souviendra pas naturellement de toutes les expériences déjà réalisées.

Vous voyez, ce type de problème engendre tant d’enjeux. Même si vous parvenez à converger vers une recette numérique satisfaisante, il suffit d’une disruption – qu’il s’agisse de confinements ou autre – pour que vous deviez refaire toute la recette. Si votre processus itératif est incroyablement lent, vous échouerez systématiquement à faire face à toutes les perturbations. Au moment où vous aurez enfin mis au point la solution pour une perturbation, vous serez déjà passé à autre chose. Vous devez donc disposer de quelque chose d’extrêmement performant pour que vos itérations soient très rapides.

Et cela apporte également une autre dimension, à savoir que pour améliorer la performance d’une itération à l’autre, vous pouvez contourner certaines étapes. Car peut-être que d’une expérience à l’autre, vous allez refaire la plupart des mêmes calculs. Faut-il alors redéployer toutes ces ressources alors qu’en réalité, vous réalisez presque exactement la même recette numérique avec quelques légères divergences ? Peut-être, avec une approche intelligente, pourriez-vous recycler la majeure partie de ce que vous avez déjà calculé afin d’itérer beaucoup plus rapidement sans tout refaire à chaque fois.

Mais encore, cela ne fonctionnera que si vous parvenez à comprendre, en quelque sorte, où vont vos ressources informatiques, ce que vous gaspillez, ce que vous faites deux ou dix fois d’affilée alors que vous ne devriez le faire qu’une seule fois.

Conor Doherty : D’accord, Joannes, les auditeurs d’aujourd’hui, et je suis sûr qu’ils se disent tous : « Je suis d’accord avec cet homme. J’ai confiance en lui. Il est digne de confiance. » Quelles sont les prochaines étapes immédiates pour, disons, le praticien moyen de la supply chain et les dirigeants de niveau C qui vous écoutent et pensent : « D’accord, je veux être plus avisé dans ces domaines » ?

Joannes Vermorel : Je dirais qu’il faut commencer à lire des documents introductifs sur le fonctionnement des ordinateurs. Il existe de nombreux livres qui expliquent comment fonctionnent les ordinateurs et qui vous aideront à acquérir une compréhension, par exemple, de ce qui est vendu par les fournisseurs de cloud computing. Vous savez, vous pouvez vérifier, tous les prix sont publics. Vous pouvez donc aller sur Microsoft Azure et voir : « D’accord, quels sont les niveaux de prix pour le stockage, pour les CPU, pour les machines virtuelles, pour la bande passante, etc. ? » Cela ne prend que quelques heures. Il existe, je dirais, des ouvrages élémentaires. Il y a même des livres destinés aux lycéens ou aux collégiens, et c’est parfait. L’idée est d’acquérir ces connaissances.

Et ensuite, chaque fois qu’une question d’évolution technologique se pose, interrogez le fournisseur, interrogez le consultant : « D’accord, quelle est votre vision des ressources informatiques ? Nous souhaitons prendre les meilleures décisions selon les métriques et objectifs que vous vous fixez. » Engagez la discussion sur la manière dont ces ressources informatiques brutes que j’achète se traduisent par des décisions optimales. Si les personnes auprès desquelles vous allez acheter beaucoup de choses n’ont aucune idée à ce sujet, alors vous devriez fuir. C’est ce que je retiens. Utilisez cela comme un test décisif pour déceler les soi-disant experts qui ne devraient même pas l’être et qui sont absolument, je dirais, incompétents.

Parce qu’en fin de compte, si vous optez pour ce genre de fournisseurs, vous finirez par payer le prix de leur inefficacité. Et ce coût sera double. D’une part, vous paierez beaucoup plus pour le matériel informatique, au point que cela devient extravagant. En règle générale, lorsque Lokad vend un abonnement, nous sommes bien en dessous du coût de nos concurrents rien que pour les ressources informatiques, sans même prendre en compte la main-d’œuvre, le personnel d’ingénierie nécessaire à l’installation et à la maintenance. Lokad se situe tout simplement en dessous du coût matériel.

C’est donc un point. Mais ensuite, il y aura quelque chose d’encore plus important : votre fournisseur vous cantonnera à des recettes ultra-simplistes, en essayant de vous convaincre que c’est le meilleur que la science puisse offrir, alors qu’en réalité, cela reflète simplement son incapacité à exploiter correctement les ressources informatiques. C’est pourquoi vous vous retrouvez avec des choses ultra-simplistes comme les stocks de sécurité, qui restent encore courants. Au fond, les fournisseurs savent que c’est complètement nul. Mais le problème, c’est qu’ils sont tellement inefficaces dans l’utilisation de leurs ressources informatiques que, pour eux, il serait totalement impraticable d’envisager des solutions bien meilleures.

Vous voyez, un coût double : un coût direct, qui correspond à des dépenses extravagantes en ressources informatiques qui n’ont aucun sens, et ensuite il y a le second ordre de coût, qui vous contraint à adopter des recettes simplistes où, en fin de compte, vous, en tant que praticien, serez obligé d’intervenir avec vos tableurs pour corriger manuellement toute la folie qui ressort de ces systèmes. Pourquoi ? Parce que le système utilise des recettes excessivement simplistes qui vous délèguent pratiquement toutes les subtilités, la recette étant simpliste et ne traitant d’aucune forme de sophistication.

Conor Doherty: Il y avait en fait, non pas une analogie mais une véritable règle empirique que vous avez utilisée plus tôt, ou plutôt une question, excusez-moi. Vous avez dit, “Si vous ne savez pas comment ou combien coûte un téraoctet de cloud computing ou quelque chose dans ce genre, si vous n’avez même pas l’ordre de grandeur, c’est fondamentalement un problème.” Et c’est intéressant quand vous dites cela, car la plupart des gens dans leur vie personnelle, même les auditeurs, s’ils entraient dans un café pour commander un café et qu’on leur disait, “D’accord, cela fait 45 €”, ils rechigneraient. Ils seraient choqués et diraient, “D’accord, eh bien, ce n’est pas correct. Je ne sais pas combien vous devriez me facturer personnellement, mais 45 € c’est un peu élevé.” Et ils partiraient vraisemblablement pour aller ailleurs.

Même si c’est dans une zone touristique, vous diriez quand même, “45, non, ce n’est pas correct.” Mais en fin de compte, rien n’en dépend. Je veux dire, vous n’allez pas vous ruiner, du moins pas financièrement. Vous n’allez pas perdre votre emploi à cause de cela.

Cependant, ce même type d’instinct, l’instinct de survie, ou simplement cette perspicacité globale peut être totalement absent lorsqu’il s’agit de, “D’accord, je dois prendre des décisions très coûteuses concernant le type de ressources informatiques ou de logiciels que l’entreprise va utiliser.” Les coûts directs et indirects à long terme, ainsi que les coûts indirects à court terme et à long terme, sont incommensurables. Genre, “Oh, cela coûte 555,000 par seconde d’informatique, ou quelque chose comme ça.” Encore une fois, cela pourrait en fait être exact. Je ne sais pas, probablement pas. Mais l’essentiel étant que, si vous ne pouvez pas répondre à ces questions, je conviens qu’il y a un énorme vide dans vos connaissances professionnelles que vous devriez chercher à combler.

Joannes Vermorel: Oui, encore une fois, c’est peut-être un peu exigeant pour les praticiens de supply chain, mais qu’est-ce qui est en jeu ? De gros budgets. Je veux dire, les grandes entreprises dépensent volontairement des millions, et parfois des dizaines de millions d’euros ou de dollars par an pour ces systèmes. Et je suis toujours complètement sidéré quand on peut dépenser autant et que personne, fournisseur compris, n’ait la moindre idée de ces problèmes fondamentaux.

Encore une fois, ce serait comme acheter un bâtiment parce que c’est quelque chose de très coûteux. C’est donc comme acheter un bâtiment et avoir un architecte qui n’a aucune idée de ce qu’est réellement le béton. Vous diriez, “Vous savez quoi, je ne suis pas sûr. Peut-être que le bâtiment est fait de carton, de béton, ou peut-être de bois, ou même de guimauves. Vous savez, je m’en fiche, il suffit d’y mettre de la peinture et tout se ressemble.”

Vous savez, encore une fois, je pense que le domaine de l’informatique et des logiciels, vous savez, l’industrie du logiciel est très particulier à cet égard. Il y a énormément d’argent en jeu et il existe ce consensus implicite selon lequel le fait que tout le monde soit complètement ignorant sur le sujet est tout à fait acceptable. Et cela est, pour moi, une industrie très intrigante.

Et j’ai parlé avec la plupart de mes concurrents, et quand je dis mes concurrents, je veux dire les équipes dirigeantes. Je suis toujours sidéré quand personne n’a la moindre idée de ce qu’est cette sorte de sympathie mécanique, où l’on comprend de manière élémentaire ce qui se cache derrière.

Encore une fois, cela pourrait être, imaginez un pilote de Formule 1 qui dirait, “Vous savez quoi, j’ai quatre roues. Qu’est-ce qui se passe entre la pédale et les roues ? Vous savez, c’est de la magie, de la magie. Vous savez, il y a des choses. Ça fait beaucoup de bruit. Je sais que c’est bruyant, mais à part cela, il y a juste des choses.” Vous savez, dans ma vision, la voiture, ce sont des choses. C’est ce niveau de granularité qui ferait que, vous savez, les gens penseraient que c’est insensé. Vous devriez en savoir bien plus si vous comptez bien utiliser la voiture.

De mon point de vue, je pense que les praticiens de supply chain utilisent des tonnes d’outils digitaux chaque jour, tout comme un pilote de Formule 1 utilise une Formule 1. Ainsi, ils doivent comprendre un peu afin de développer cette sympathie mécanique quant à ce qui se passe, comment ces choses fonctionnent, pour pouvoir prendre des décisions éclairées. Au moins pour éviter qu’on leur vende des choses complètement absurdes qui finissent par échouer pour des raisons entièrement évitables.

Conor Doherty: Je n’aurais pas pu mieux le formuler moi-même. Merci, et merci beaucoup pour votre temps. Je n’ai plus de questions, et merci infiniment de nous avoir regardés. On se retrouve la prochaine fois.